CVE-2024-56327

What it actually does

This vulnerability affects pyrage versions that include age plugin support, specifically pyrage 1.2.0 through versions before 1.2.3. pyrage delegates encryption and decryption behavior to the Rust age crate, which had a plugin-handling flaw related to GHSA-4fg7-vxc8-qx5w. When plugin support is enabled or reachable, crafted age input can cause unsafe invocation of an external age plugin process. In practical terms, an application that decrypts or processes attacker-supplied age files may be coerced into launching an unintended local executable or plugin under the privileges of the application process, resulting in remote code execution in server-side processing workflows. pyrage versions before 1.2.0 are not affected because they did not include plugin support.

Why it matters to the business

Systems that use vulnerable pyrage or the affected Rust age implementation to process untrusted encrypted files could allow an attacker to execute code with the privileges of the application performing decryption. This can lead to application takeover, data theft, tampering with encrypted or decrypted content, credential exposure, lateral movement, and service disruption. The issue has a critical CVSS score, but current public exploitation signals are low: it is not listed in CISA KEV, is not known to be used in ransomware campaigns, and the provided EPSS score is low. Organizations should still prioritize remediation wherever pyrage or age is used in automated file-processing, upload, backup, CI/CD, messaging, or secrets-handling workflows because exploitation impact is high if the vulnerable code path is reachable.

How an attack unfolds

An attacker first identifies an application, service, automation job, or developer tool that uses pyrage or the Rust age crate to decrypt or inspect age-encrypted content. The attacker then supplies a specially crafted age file or message that references plugin functionality in a way that reaches the vulnerable plugin invocation logic. If the target environment has plugin support available and the attacker can satisfy the required execution preconditions, such as influencing the processed file and, in some cases, the local plugin execution context, the vulnerable library may launch an unintended age plugin or executable. The launched code runs with the same operating-system privileges, environment variables, file-system access, and network access as the process using pyrage. After code execution, the attacker may collect secrets, read decrypted data, modify application state, install persistence, or pivot to other systems accessible from the compromised process.

How to fix it

Upgrade pyrage to version 1.2.3 or later. If consuming pyrage directly from source, update to a revision containing woodruffw/pyrage commit ec398c4a38a1d2e184458c96153df89e606b0ba5 or later. If using the Rust age crate or tooling derived from the reference age implementation, update to a fixed release or a revision containing the relevant fix; the provided fixed Git reference for filosottile/age is bbe6ce5eeb1bb70cfc705d0961c943f0dd637ffd. For Ubuntu-listed package exposure, ensure affected Moodle packages are updated to fixed package version 3.0.3+dfsg-0ubuntu1 or later where applicable, but verify package relevance because this advisory primarily concerns pyrage and age plugin behavior. There are no known safe workarounds for the vulnerable pyrage versions. As compensating controls until updates are complete, avoid processing untrusted age files, disable or remove age plugin execution paths where operationally possible, run decryption workers with least privilege, restrict PATH and executable directories, isolate file-processing workloads in containers or sandboxes, and block outbound network access from decryption workers unless explicitly required.

How to confirm the fix worked

Confirm package versions using dependency manifests, lockfiles, SBOMs, container images, and runtime package inspection. For Python environments, check installed pyrage versions with commands such as `python -m pip show pyrage`, `pip freeze`, Poetry/Pipenv lockfiles, or SBOM inventory and verify the version is 1.2.3 or later. For source-based deployments, verify the deployed pyrage revision includes commit ec398c4a38a1d2e184458c96153df89e606b0ba5 or later. For Rust or age consumers, verify the age dependency or binary has been updated to a fixed release or includes commit bbe6ce5eeb1bb70cfc705d0961c943f0dd637ffd or later where that implementation is used. Confirm that pyrage versions before 1.2.0 are not mistakenly flagged as vulnerable solely by name, because they lack plugin support. After remediation, test representative encryption/decryption workflows to ensure plugin behavior still works only as intended, and review process telemetry to confirm decryption operations are not unexpectedly spawning age-plugin executables from writable or untrusted locations.

Typical attack path

1. Identify a service, script, worker, or application that uses pyrage 1.2.0 through before 1.2.3, or an affected Rust age implementation, to process age-encrypted content.
2. Deliver attacker-controlled age input through an upload, API request, message queue, repository, backup workflow, or other file-processing path.
3. Craft the age payload so that plugin handling is invoked during decryption or parsing.
4. Meet any environmental preconditions needed for exploitation, such as the presence or influence of executable age plugin behavior in the target runtime context.
5. Trigger the vulnerable code path when the application processes the supplied age content.
6. Achieve execution of attacker-controlled or unintended code under the privileges of the application process.
7. Use the foothold to access decrypted files, credentials, application data, or adjacent systems.

How to detect it

There are no universal network indicators for this issue because exploitation depends on how applications receive and process age-encrypted content and on local plugin execution behavior. To determine whether exploitation already occurred, review EDR, Sysmon, Linux auditd, shell history, process accounting, container runtime logs, and application logs for unexpected execution of age plugin binaries, especially processes named `age-plugin-*` spawned by `python`, `python3`, web workers, queue workers, CI runners, backup jobs, or file-processing services. Correlate suspicious plugin execution with recent uploads, API requests, repository changes, message-queue events, or files beginning with the age file format header. Investigate any plugin executable launched from writable locations such as temporary directories, application upload directories, user home directories, build workspaces, or container writable layers. Review file-system artifacts for newly created or modified executable files near the time of decryption events. Examine outbound network connections from decryption workers shortly after age processing, especially if those workers normally do not initiate external connections. If centralized Python dependency logs or SBOM history are available, identify the time window during which pyrage 1.2.0 through before 1.2.3 was deployed and focus forensic review on that period.

• age-plugin-
• python -m pip show pyrage
• pyrage==1.2.0
• pyrage==1.2.1
• pyrage==1.2.2
• site-packages/pyrage
• age-encryption.org/v1
• -----BEGIN AGE ENCRYPTED FILE-----
• /tmp/age-plugin-
• /var/tmp/age-plugin-
• /dev/shm/age-plugin-

What your security team should do

• Inventory all Python applications, services, containers, developer tooling, and automation jobs that include pyrage or process age-encrypted content.
• Prioritize patching internet-facing, file-upload, message-processing, CI/CD, backup, secrets-management, and multi-tenant workflows that decrypt attacker-supplied or user-supplied age files.
• Upgrade pyrage to 1.2.3 or later, and update affected age implementations to fixed revisions or releases.
• Treat source installs, vendored dependencies, container layers, and build artifacts as in scope; do not rely only on top-level package manifests.
• Temporarily stop or isolate workflows that decrypt untrusted age files if they cannot be upgraded quickly.
• Run decryption and file-processing workers under dedicated low-privilege accounts with restricted file-system access and minimal network egress.
• Harden plugin execution paths by removing unneeded age plugins, restricting writable directories from PATH, and monitoring execution of age-plugin binaries.
• Hunt historical process, EDR, and audit logs for unexpected age-plugin execution spawned by Python applications or file-processing workers.
• Add dependency scanning rules that flag pyrage versions >=1.2.0 and <1.2.3 as vulnerable while excluding versions <1.2.0 from this specific plugin issue.
• Because there is no KEV listing and EPSS is low, align urgency with exposure: patch immediately where untrusted content is processed, and patch during the next security update cycle for isolated development-only use.