CVE-2025-54059
Executive Summary
CVE-2025-54059 is a vulnerability in the melange tool, which is used to build APK packages for Alpine Linux and similar distributions using declarative pipelines. The flaw resides in the generation of Software Bill of Materials (SBOM) files within the built APK packages. Specifically, SBOM files are created with overly permissive file system permissions of mode 666 (read/write for all users). This misconfiguration allows any unprivileged user on a running system to tamper with the SBOM content. While this does not directly compromise the package integrity or execution, it can mislead security scanners that rely on SBOM data for vulnerability detection and dependency mapping. Under specific conditions, an attacker could also cause a denial of service (DoS) by corrupting the SBOM in a way that crashes scanning tools. The issue affects melange versions from 0.23.0 up to (but not including) 0.29.5. The fix is implemented in version 0.29.5, which restricts SBOM file permissions to a secure default.
Note: This vulnerability is not related to any WordPress plugin or component; it is a build-tool issue within the Alpine/melange ecosystem.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
CVSS Breakdown & Threat Level
- CVSS Score: 4.4 (Medium)
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
- Attack Vector (AV): Local – the attacker must have local access to the running system.
- Attack Complexity (AC): Low – no special conditions required.
- Privileges Required (PR): Low – the attacker needs only unprivileged user access.
- User Interaction (UI): None – no user action needed.
- Scope (S): Unchanged – the impact stays within the same security boundary.
- Confidentiality (C): None – no data exposure.
- Integrity (I): Low – SBOM data can be modified, affecting scanner accuracy.
- Availability (A): Low – potential DoS against scanning tools.
Threat Level: Medium. The vulnerability is local and requires an existing foothold, but it can degrade security monitoring and cause operational disruption.
Deep Dive & Mechanics
The melange build tool generates APK packages that include an SBOM file (typically named .SBoM or similar) inside the package archive. This SBOM contains metadata about the package's dependencies, versions, and provenance. During the build process, melange creates this file with file permissions set to 0666 (read and write for owner, group, and others). This is a deviation from the standard secure practice of using 0644 (read for all, write only for owner) or 0600 (read/write only for owner).
On a running system where the APK is installed, any unprivileged user can modify the SBOM file because the permissions allow world-writable access. The attack scenario is as follows:
- An attacker gains low-privilege access to a container or host (e.g., via a compromised application).
- The attacker locates the SBOM file (e.g.,
/var/lib/apk/sbom/package-1.0.sbom). - The attacker modifies the SBOM content – for example, removing a known vulnerable dependency, adding a fake dependency, or corrupting the JSON/XML structure.
- Security scanners (e.g., Trivy, Grype, Snyk) that read the SBOM to generate vulnerability reports will now see tampered data. This can lead to false negatives (missing real vulnerabilities) or false positives (reporting non-existent issues).
- If the attacker corrupts the SBOM format severely, the scanner may crash or hang, causing a denial of service.
The root cause is a missing permission restriction in the file creation logic within melange's SBOM generation code. The fix in version 0.29.5 changes the file mode to 0644 or a more restrictive value.
Vulnerable vs. Patched Code
Vulnerable Code (melange < 0.29.5):
// In sbom.go or similar
func writeSBOM(path string, data []byte) error {
// Incorrect: creates file with 0666 permissions
return os.WriteFile(path, data, 0666)
}
Patched Code (melange >= 0.29.5):
// In sbom.go or similar
func writeSBOM(path string, data []byte) error {
// Correct: restricts permissions to 0644
return os.WriteFile(path, data, 0644)
}
The change is minimal but critical: the file mode constant is changed from 0666 to 0644. This ensures that only the file owner (root) can write to the SBOM, while all users can still read it (necessary for scanners).
Exploitation & Lab Setup
Red Team (Attack Simulation)
Prerequisites:
- A running Alpine Linux container or host with melange-built APK packages (version 0.23.0 to 0.29.4).
- Low-privilege shell access (e.g.,
nobodyuser).
Steps:
- Identify the SBOM file location. Typically, it is stored under
/var/lib/apk/sbom/or alongside the package data.find /var -name "*.sbom" -type f 2>/dev/null - Check current permissions:
ls -la /var/lib/apk/sbom/example-package-1.0.sbom # Expected: -rw-rw-rw- (0666) - Tamper with the SBOM content. For example, remove a known vulnerable dependency:
# Backup original cp /var/lib/apk/sbom/example-package-1.0.sbom /tmp/original.sbom # Use sed or jq to modify (assuming JSON format) jq 'del(.packages[] | select(.name == "openssl"))' /var/lib/apk/sbom/example-package-1.0.sbom > /tmp/modified.sbom cp /tmp/modified.sbom /var/lib/apk/sbom/example-package-1.0.sbom - Alternatively, corrupt the file to cause a scanner crash:
echo "corrupted data" > /var/lib/apk/sbom/example-package-1.0.sbom
Expected Outcome: Security scanners will now report inaccurate data or fail to parse the SBOM.
Blue Team (Detection & Hardening)
Detection:
- Monitor for unexpected writes to SBOM files by non-root processes.
- Use file integrity monitoring (e.g., AIDE, Tripwire) on SBOM directories.
- Alert on SBOM files with permissions other than
0644.
Hardening:
- Immediately upgrade melange to version 0.29.5 or later.
- As a workaround, manually fix permissions on existing SBOM files:
find /var/lib/apk/sbom -type f -exec chmod 0644 {} \; - Implement a cron job or systemd timer to periodically check and correct SBOM permissions.
- Restrict write access to the SBOM directory using
chmod 755and ensure only root can write.
Indicators of Compromise (IOCs)
- File Permissions: SBOM files with mode
0666(e.g.,-rw-rw-rw-). - File Paths:
/var/lib/apk/sbom/*.sbomor similar paths depending on distribution. - Process Anomalies: Non-root processes (e.g.,
nobody,www-data) writing to SBOM files. - Scanner Errors: Security scanners reporting parsing errors or unexpected dependency lists for previously scanned packages.
- Log Entries: Scanner logs showing
permission deniedorunexpected EOFwhen reading SBOM files.
Detection Engineering
YARA Rule
rule CVE_2025_54059_SBOM_Permissions {
meta:
description = "Detects SBOM files with world-writable permissions (0666) indicative of CVE-2025-54059"
author = "Valters IT"
date = "2025-04-10"
severity = "medium"
strings:
$sbom_magic = { 7B 22 } // JSON start "{" or similar SBOM header
condition:
// Check for file permissions 0666 (rw-rw-rw-)
// This rule is designed to be run on file metadata, not content
// In practice, use a file scanning tool that provides permission info
false
}
Sigma Rule
title: CVE-2025-54059 - World-Writable SBOM File Creation
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects creation of SBOM files with overly permissive permissions (0666) by melange
author: Valters IT
date: 2025-04-10
logsource:
category: file_event
product: linux
detection:
selection:
TargetFilename|endswith: '.sbom'
TargetFilename|contains: '/var/lib/apk/sbom/'
FilePermissions: '0666'
condition: selection
falsepositives:
- Manual administrative changes (rare)
level: medium
Suricata Rule
alert tcp any any -> any any (msg:"CVE-2025-54059 - Potential SBOM Tampering via Network"; content:"|7b 22|"; depth:2; fileext:"sbom"; classtype:attempted-user; sid:1000001; rev:1;)
Note: This Suricata rule is a placeholder for network-based detection of SBOM file transfers. In practice, the vulnerability is local, so network detection is less relevant. Focus on host-based monitoring.
Remediation & Mitigation
Immediate Actions:
- Upgrade melange to version 0.29.5 or later. This is the official fix.
# For Alpine Linux apk upgrade melange - Fix existing SBOM permissions on all running systems:
find /var/lib/apk/sbom -type f -exec chmod 0644 {} \;
Long-Term Mitigations:
- Implement file integrity monitoring (FIM) on SBOM directories.
- Use a security scanner that validates SBOM file permissions before parsing.
- Restrict local user access to production systems (principle of least privilege).
- Regularly audit file permissions on critical system files.
Workaround (if upgrade is not possible):
- Create a systemd service or cron job that runs every minute to reset SBOM permissions:
# /etc/cron.d/fix-sbom-perms * * * * * root find /var/lib/apk/sbom -type f -exec chmod 0644 {} \;
Valters IT
DevSecOps & Cyber Threat Intelligence