CVE-2025-53945: 
Wolfi vulnerability analysis and mitigation

CVE-2025-53945 is an incorrect default permissions vulnerability in Chainguard's apko, a tool for building and publishing OCI container images from apk packages. Introduced in version 0.27.0 via commit 04f37e2 ("generate /etc/ld.so.cache"), the /etc/ld.so.cache file in generated container images was inadvertently created with world-writable permissions (mode 0666), enabling potential local privilege escalation to root. All versions from 0.27.0 through 0.29.4 are affected; version 0.29.5 contains the fix. The vulnerability carries a CVSS v3.1 base score of 7.0 (High) (GitHub Advisory).

The root cause is CWE-276 (Incorrect Default Permissions): when apko generates /etc/ld.so.cache during image build, it uses Go's os.Create() internally, which creates the file with default permissions of 0666 (read/write for all users), rather than the appropriate 0644. The dynamic linker (ld.so) consults this cache file at runtime to locate shared libraries, so a world-writable cache allows any local user to inject additional library search directories or replace cached entries. The fix in commit aedb077 adds an explicit fsys.Chmod("etc/ld.so.cache", 0644) call after writing the cache file (GitHub Advisory, Fix Commit). Exploitation requires low-privilege local access and high attack complexity, as the attacker must craft and place a malicious shared library in a directory they control and manipulate the cache to reference it (GitHub Advisory).

A local unprivileged user inside a container image built with affected apko versions could overwrite /etc/ld.so.cache to inject malicious shared library paths, potentially causing privileged processes to load attacker-controlled libraries and escalating privileges to root. This compromises confidentiality (high — access to sensitive data via root), integrity (low — modification of the dynamic loader path), and availability (low — potential disruption of services relying on the loader cache). The scope is marked as Changed, meaning the impact can extend beyond the initially compromised container process (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.012% (0.000120), reflecting a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires local access with low privileges and high attack complexity, limiting the practical attack surface.

1. Gain local access: Obtain a shell inside a container built with apko versions 0.27.0–0.29.4 as a low-privileged user.
2. Verify the misconfiguration: Confirm that /etc/ld.so.cache is world-writable by running ls -la /etc/ld.so.cache or find / -type f -perm -o+w /etc/ld.so.cache.
3. Prepare a malicious shared library: Compile a shared library (e.g., a .so file) that executes attacker-controlled code (e.g., spawning a root shell or adding a backdoor user) when loaded.
4. Place the library in an attacker-controlled directory: Copy the malicious .so file to a directory writable by the attacker (e.g., /tmp/evil/).
5. Overwrite /etc/ld.so.cache: Craft or modify the binary cache file to include /tmp/evil/ as a library search path, or replace an existing library entry with the malicious one. Tools like a custom Go program or binary patching can be used to write a valid ld.so.cache format.
6. Trigger library loading by a privileged process: Wait for or trigger a setuid binary or privileged service to execute, causing ld.so to consult the tampered cache and load the malicious library, achieving code execution as root (GitHub Advisory).

• File System: Presence of /etc/ld.so.cache with permissions 0666 (-rw-rw-rw-) in container images built with apko v0.27.0–v0.29.4; unexpected .so files in world-writable directories such as /tmp/ or /dev/shm/.
• File System: Modification timestamp on /etc/ld.so.cache that postdates container startup, indicating runtime tampering.
• Process: Unusual child processes spawned by setuid binaries or privileged daemons (e.g., unexpected shells or network tools) that could indicate malicious library injection.
• Logs: Audit log entries (if auditd is enabled) showing write operations to /etc/ld.so.cache by non-root users; dynamic linker debug output (LD_DEBUG=libs) showing libraries loaded from unexpected paths.

Upgrade apko to version 0.29.5 or later, which corrects the file permissions on /etc/ld.so.cache to 0644 via commit aedb077 (apko v0.29.5 Release). As an interim workaround for already-built images, manually correct the permissions by running chmod 0644 /etc/ld.so.cache within affected containers or as part of the image build process. Additionally, rebuild all container images using the patched apko version to ensure newly generated images contain the correct permissions. Organizations should also audit running containers for the world-writable cache file and apply least-privilege principles to container workloads (GitHub Advisory).

The vulnerability was reported by Cody Harris from H2O.ai and coordinated by eslerm, with the fix developed by Vishal Choudhary (GitHub Advisory). The issue was included in the CISA weekly vulnerability bulletin for the week of July 14, 2025, indicating it received standard government tracking attention. No significant broader media coverage or notable researcher commentary beyond the GitHub advisory has been identified.