ZION BOGGAN
← THE INDEX  ·  WRITEUP

AXIS OS SNMP Community String Disclosure to Viewer-Privileged Users

The YAML access control definition grants viewer-level users GET access to SNMP community strings, while correctly restricting SET to admin only. Community strings are the sole authentication mechanism for SNMP v1/v2c.

2026 AXIS OSSensitive Data ExposurePrivilege EscalationFirmware

Summary

The AXIS OS DeviceConfig1 framework exposes SNMP configuration through a REST API backed by YAML access control definitions. In the SNMP API definition (api-def_snmp_v1.yaml), the readCommunity, writeCommunity, and trap community fields all have get operations with roles [viewer, operator, admin], while set correctly restricts to [admin].

SNMP v1/v2c community strings are plaintext passwords: possession of the write community string is functionally equivalent to admin access over SNMP. A viewer-level user (the lowest authenticated privilege) can read these credentials in a single API call, then use them with any standard SNMP client to gain write access to the device, bypassing VAPIX role-based access control entirely.

The write path was secured; the read path for the same credential fields was not. The asymmetry is visible in the firmware YAML and confirmed against the D-Bus transport policy, which grants viewer access to the DeviceConfig1 APIGateway1 interface.

Impact

A viewer-level authenticated user can:

  1. Read readCommunity and writeCommunity strings with a single GET request
  2. Use the writeCommunity string with any SNMP v1/v2c client to modify camera settings, which is admin-equivalent for device configuration
  3. Use the readCommunity string to read the full SNMP MIB tree, including all device configuration

In typical enterprise camera deployments, SNMP community strings are shared across multiple devices. Disclosure from one camera can enable write access to an entire fleet from a single viewer account.

Root cause

The SNMP API definition at /usr/share/dev-conf/conf-units/api-def_snmp_v1.yaml defines access control per-field:

readCommunity:
  operations:
    get:
      roles: [viewer, operator, admin]   # viewer can read
    set:
      roles: [admin]                      # only admin can write
writeCommunity:
  operations:
    get:
      roles: [viewer, operator, admin]   # viewer can read
    set:
      roles: [admin]                      # only admin can write

The dev-conf-service Rust binary enforces these rules via D-Bus. The D-Bus policy confirms viewer-group principals can call the APIGateway1 interface. The YAML is the definitive source of truth for what those callers can read.

The fix is a one-line change per field: change the get roles for all three credential properties from [viewer, operator, admin] to [admin].

Proof of concept

The following reproduces the disclosure. All camera identifiers have been replaced with placeholders.

Disclosure and fix

Reported to the AXIS Security team through coordinated disclosure.

The immediate fix: in api-def_snmp_v1.yaml, change the get roles for readCommunity, writeCommunity, and trap community from [viewer, operator, admin] to [admin]. The same audit should be applied to all other DeviceConfig1 configuration units for any field that holds a credential, key, or password.

Longer term: community strings should be treated as write-only secrets at the API layer, readable only at the moment of configuration and masked (or omitted) on subsequent reads, regardless of role.