CVE-2023-47480

What it actually does

Local privilege escalation via abuse of the set*id() function allowing an unauthenticated local process to obtain elevated privileges.

Why it matters to the business

Attackers who already have a foothold on a system can obtain full control of the affected multimedia application and any data or resources it can access, increasing the blast radius of an initial compromise.

How an attack unfolds

An attacker with local access to a system running the vulnerable Pure Data version invokes or triggers the set*id() function in a way that elevates their privileges without authentication.

How to fix it

Upgrade Pure Data to version 0.54-1 or commit 0b5e467b8728b3ed56e1a8ee5b367ce78e7e6e5d. If maddy is present, ensure it is at least version 0.5.2.

How to confirm the fix worked

Confirm the installed Pure Data binary or source matches a fixed version or commit; run the application under a non-root account and verify that privilege-escalation attempts via set*id() are rejected.

Typical attack path

1. Obtain local access to a host running Pure Data 0.54-0
2. Identify or craft input that reaches the vulnerable set*id() code path
3. Execute the function to escalate from unprivileged to higher-privileged context
4. Leverage the new privileges to access files, processes, or devices previously restricted

How to detect it

Review process execution logs, auditd records, and application startup logs for unexpected privilege changes or invocations of set*id() originating from Pure Data binaries; correlate with file-access anomalies after Pure Data execution.

What your security team should do

• Prioritize upgrade of all Pure Data installations to the fixed release within the next patch cycle
• Inventory hosts running Pure Data and restrict local user access where possible
• Add Pure Data version checks to configuration-management and vulnerability-scanning pipelines