CVE-2022-37061

What it actually does

This vulnerability is an unauthenticated network-accessible command injection flaw in FLIR AX8 thermal sensor cameras running firmware version 1.46.16 or earlier. The vulnerable res.php endpoint accepts an HTTP POST parameter named id and improperly passes attacker-controlled input to the underlying operating system shell. Because the affected service runs with root privileges, successful exploitation allows arbitrary operating system command execution as root, giving the attacker full control of the camera, including the ability to read or modify configuration, alter sensor behavior, install persistence, pivot to adjacent systems, disrupt availability, or use the device as part of a botnet or scanning infrastructure.

Why it matters to the business

A compromised thermal camera can be fully taken over remotely, which may affect physical monitoring, industrial process visibility, safety workflows, facility operations, and network security. Because exploitation requires no authentication, has low complexity, and has a very high EPSS score with weaponized exploit maturity, internet-exposed or broadly reachable AX8 devices should be treated as high-priority assets. Operational consequences can include loss of thermal monitoring, manipulated readings, device outages, unauthorized surveillance access, lateral movement from an embedded device, and reputational or compliance impact if the device is used in regulated monitoring environments.

How an attack unfolds

An attacker first identifies a reachable FLIR AX8 camera, commonly by scanning for exposed web interfaces or fingerprinting FLIR AX8 firmware. The attacker then sends a crafted HTTP POST request to the /res.php endpoint with malicious shell syntax embedded in the id parameter. Because the application does not safely validate or escape the parameter before invoking system commands, the injected command is executed by the device operating system. Since the vulnerable service executes with root privileges, the attacker gains root-level command execution. After initial execution, the attacker may enumerate the device, dump configuration and credentials, modify camera settings, download additional tooling, establish persistence, disable services, use the camera as a foothold for internal reconnaissance, or enroll it into automated botnet activity.

How to fix it

Upgrade affected FLIR AX8 cameras and AX8 firmware running version 1.46.16 or earlier to a vendor-provided fixed firmware version if available. No fixed version was provided in the supplied advisory data, so administrators should verify the latest firmware directly with Teledyne FLIR support or official product downloads and apply the newest supported release. If an upgrade is not immediately available, remove AX8 web interfaces from internet exposure, restrict access to trusted management networks only, enforce firewall or ACL rules so only approved administrator workstations can reach the device, place cameras on a segmented OT/IoT VLAN, and block inbound access to the vulnerable web service from untrusted networks. Where possible, require VPN or jump-host access for administration, disable unused services, rotate any credentials stored on or used by the camera, and rebuild or factory-reset devices that show signs of compromise before returning them to service.

How to confirm the fix worked

Inventory all FLIR AX8 cameras and confirm firmware versions through the device interface, management tooling, or authenticated device inspection. Devices running version 1.46.16 or earlier should be considered vulnerable unless the vendor confirms otherwise. Validate remediation by confirming the installed firmware is newer than the affected range or is explicitly listed by the vendor as fixed. Confirm that /res.php is not reachable from untrusted networks and that network controls restrict access to approved management sources. Perform a safe validation test by checking whether unauthenticated POST access to /res.php is blocked or appropriately rejected, without executing operating system commands. Review firewall, reverse proxy, and web server logs to ensure no recent suspicious POST requests to /res.php were observed before or after remediation.

Typical attack path

1. Scan networks or the internet for exposed FLIR AX8 camera web interfaces.
2. Confirm the device model or vulnerable firmware version is AX8 firmware 1.46.16 or earlier.
3. Send an unauthenticated HTTP POST request to /res.php containing command metacharacters or shell syntax in the id parameter.
4. Execute a simple command to confirm code execution, such as device enumeration or outbound network callback.
5. Run additional commands as root to inspect configuration, users, network interfaces, and reachable internal systems.
6. Optionally download tools or scripts using built-in utilities such as wget, curl, tftp, busybox, or nc if present.
7. Modify device configuration, establish persistence, disrupt camera services, pivot further into the network, or use the camera for scanning and botnet activity.

How to detect it

To determine whether exploitation has already occurred, review logs from the camera web interface if available, upstream firewalls, reverse proxies, web proxies, IDS/IPS sensors, NetFlow, DNS logs, and DHCP records for suspicious access to FLIR AX8 devices. Focus on HTTP POST requests to /res.php, especially where the POST body includes an id parameter containing shell metacharacters such as semicolons, pipes, backticks, command substitution, redirection, or chained commands. Look for command names commonly used after embedded-device compromise, including wget, curl, tftp, nc, netcat, telnet, sh, bash, busybox, chmod, uname, id, ps, kill, crontab, iptables, and mount. Investigate unexpected outbound connections from camera IP addresses to the internet, especially shortly after requests to /res.php. On the device, if shell access or forensic acquisition is available, look for recently modified startup scripts, cron entries, unknown binaries in writable temporary directories, suspicious processes, altered web files, modified account files, unexpected firewall rules, or unauthorized configuration changes. Because embedded devices often have limited local logging, absence of device logs does not rule out compromise; correlate network telemetry and management-plane access records around the suspected exposure window.

• POST /res.php
• /res.php
• id=
• id=;
• id=%3B
• id=|
• id=%7C
• id=`
• id=%60
• id=$(
• id=%24%28
• id=&&
• id=%26%26
• id=||
• id=%7C%7C
• id=>
• id=%3E
• id=<
• id=%3C
• POST /res.php HTTP/1.1
• wget http
• curl http
• tftp -g
• busybox wget
• /tmp/
• /var/tmp/
• /dev/shm/
• chmod +x
• uname -a
• cat /etc/passwd
• cat /etc/shadow
• /etc/init.d/
• /etc/crontab
• crontab -e
• iptables -F
• nc -e
• netcat -e

What your security team should do

• Immediately identify all FLIR AX8 cameras and determine whether any run firmware version 1.46.16 or earlier.
• Prioritize remediation for any AX8 device reachable from the internet, user networks, vendor networks, or other untrusted segments due to the 9.8 CVSS score, weaponized exploit maturity, and very high EPSS probability.
• Upgrade to the latest vendor-supported firmware or obtain remediation guidance directly from Teledyne FLIR if no fixed version is listed in asset management data.
• Restrict access to the camera web interface using firewalls, ACLs, VPNs, and management network segmentation.
• Hunt for suspicious HTTP POST requests to /res.php, especially requests containing shell metacharacters, command names, or download utilities in the id parameter.
• If exploitation is suspected, isolate the device, preserve logs and configuration, capture volatile network context where possible, reset or reimage the device, upgrade firmware, and rotate credentials associated with the camera or surrounding management systems.
• Add IDS, SIEM, or web proxy detections for command-injection patterns targeting /res.php on embedded camera web interfaces.
• Continuously monitor outbound connections from camera networks, especially unexpected DNS, HTTP, HTTPS, Telnet, SSH, TFTP, or IRC-like traffic to external hosts.