CVE-2025-6779

Executive Summary

CVE-2025-6779 is a privilege escalation vulnerability affecting Axis devices that support ACAP (Axis Camera Application Platform). The vulnerability stems from improper permissions set on an ACAP configuration file, which can be exploited by an attacker who has already convinced a victim to install a malicious, unsigned ACAP application. Once installed, the attacker can leverage the weak file permissions to inject commands and escalate privileges on the device. The CVSS score is 6.7 (Medium), and the attack vector is local, requiring user interaction. No public proof-of-concept (PoC) or exploit code is currently available. The patch status is unknown, and no official fix has been released.

CVSS Breakdown & Threat Level

• CVSS Score: 6.7 (Medium)
• Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
• Attack Vector (AV): Local (L) – The attacker must have local access to the device or be able to install a malicious application.
• Attack Complexity (AC): Low (L) – No special conditions are required beyond the attacker’s ability to deliver the malicious ACAP.
• Privileges Required (PR): None (N) – The attacker does not need any privileges to initiate the attack.
• User Interaction (UI): Required (R) – The victim must be tricked into installing the malicious ACAP.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): High (H) – Full compromise of device data.
• Integrity (I): High (H) – Full control over device operations.
• Availability (A): High (H) – Potential denial of service or device bricking.

Threat Level: Medium. Exploitation requires social engineering and the device must be configured to allow unsigned ACAPs. However, once exploited, the attacker gains full control over the device.

Deep Dive & Mechanics

The vulnerability lies in the file permissions of an ACAP configuration file. ACAP applications run in a sandboxed environment, but the configuration file for the ACAP platform itself is stored with overly permissive access rights (e.g., world-writable). This allows a malicious ACAP application (installed by the victim) to modify the configuration file and inject arbitrary commands. These commands are then executed with higher privileges (potentially root) when the ACAP service restarts or processes the configuration.

Attack Flow:

1. The attacker crafts a malicious ACAP application that, upon installation, modifies the ACAP configuration file.
2. The victim, with the device configured to allow unsigned ACAPs, installs the malicious application.
3. The malicious ACAP writes a command injection payload into the configuration file.
4. When the ACAP service reads the configuration (e.g., on restart), the injected command is executed with elevated privileges.
5. The attacker gains a root shell or persistent backdoor on the Axis device.

Root Cause: The ACAP configuration file (e.g., /etc/acap/config or similar) has permissions such as 0777 or 0666, allowing any user or process to write to it.

Vulnerable vs. Patched Code

Since no patch is available, we can only describe the vulnerable state.

Vulnerable (Incorrect Permissions):

# Vulnerable: World-writable configuration file
ls -la /etc/acap/config
-rwxrwxrwx 1 root root 1024 Jan 1 00:00 /etc/acap/config

Patched (Expected Fix):

# Patched: Restrictive permissions, only root can write
ls -la /etc/acap/config
-rw-r--r-- 1 root root 1024 Jan 1 00:00 /etc/acap/config

The patched version would also include input validation and sanitization of configuration values to prevent command injection.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Axis device with unsigned ACAP installation enabled.
• Victim interaction (social engineering to install malicious ACAP).

Lab Setup:

1. Set up an Axis device (e.g., Axis P1375) in a lab environment.
2. Enable unsigned ACAP installation via the device web interface (Settings > System > ACAP > Allow unsigned applications).
3. Create a malicious ACAP package (.eap file) that includes a script to modify the configuration file.

Exploit Steps:

1. Craft a malicious ACAP with a post-install script that writes a command to the configuration file.
2. Host the ACAP on a web server or deliver via email.
3. Convince the victim to install the ACAP on the Axis device.
4. The malicious ACAP modifies the configuration file (e.g., adds a command to /etc/acap/config).
5. Trigger a restart of the ACAP service or wait for the device to reboot.
6. The injected command executes with root privileges.

Example Malicious ACAP Script (post-install.sh):

#!/bin/sh
# Malicious post-install script
echo "command=/usr/bin/id > /tmp/pwned" >> /etc/acap/config

Blue Team (Defender)

Detection:

• Monitor for installation of unsigned ACAP applications.
• Check file permissions on ACAP configuration files.
• Look for unexpected processes or commands executed by the ACAP service.

Hunting:

• Search for files with world-writable permissions in /etc/acap/.
• Review ACAP logs for unusual configuration changes.
• Use file integrity monitoring (FIM) on critical configuration files.

Mitigation:

• Disable unsigned ACAP installation on all Axis devices.
• Restrict physical and network access to the device.
• Implement application whitelisting for ACAPs.

Indicators of Compromise (IOCs)

• File: /etc/acap/config with permissions 0777 or 0666.
• Process: Unexpected processes spawned by the ACAP service (e.g., /bin/sh, /usr/bin/id).
• Network: Outbound connections from the Axis device to unknown IPs (C2).
• Logs: ACAP logs showing configuration file modifications.
• File: Presence of files like /tmp/pwned or other indicators of command execution.

Detection Engineering

YARA Rule

rule CVE_2025_6779_Axis_ACAP_Config_Permissions {
    meta:
        description = "Detects world-writable ACAP configuration files on Axis devices"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-6779"
    strings:
        $config_path = "/etc/acap/config"
        $permissions = "rwxrwxrwx" or "rw-rw-rw-"
    condition:
        $config_path and $permissions
}

Sigma Rule

title: Axis ACAP Configuration File Permission Abuse
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects modification of ACAP configuration file with weak permissions
author: Valters IT
date: 2025/04/10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-6779
logsource:
    product: linux
    service: auditd
detection:
    selection:
        type: 'PATH'
        path: '/etc/acap/config'
        perm_mask: '0777' or '0666'
    condition: selection
falsepositives:
    - Legitimate ACAP installation by administrator
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-6779 Axis ACAP Command Injection"; flow:to_server,established; content:"/etc/acap/config"; nocase; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

1. Disable unsigned ACAP installation: Set the device to only allow signed ACAP applications from trusted sources.
2. Restrict file permissions: Manually change permissions on /etc/acap/config to 0644 or 0600 (if possible).
3. Monitor for unauthorized ACAPs: Use file integrity monitoring to detect changes to ACAP configuration files.
4. Apply vendor patch: Once available, update the Axis device firmware to the latest version.
5. Network segmentation: Place Axis devices on a separate VLAN with strict access controls.
6. User awareness: Train users not to install unsigned applications from untrusted sources.

Valters IT
Securing Digital Frontiers