FLIR AX8 1.46.16 - Remote Command Injection

FLIR AX8 (≤ 1.46.16) — Remote Command Injection (CVE-2022-37061)

This article explains the unauthenticated remote command injection vulnerability affecting FLIR AX8 devices running firmware 1.46.16 and earlier (tracked as CVE-2022-37061). It covers the technical nature of the issue, impact and risk, safe detection methods, mitigation and hardening recommendations, and incident response guidance for defenders. The content is intended to help system owners and security teams identify and remediate affected devices — not to aid exploitation.

Executive summary

• The FLIR AX8 is an industrial thermal camera/automation device. A command injection vulnerability in certain web endpoints allowed unauthenticated attackers to execute system commands remotely on affected firmware versions.
• Impact: full system compromise of the device, potential lateral movement into OT networks, data exposure, and persistence on the device.
• Mitigation: apply vendor firmware updates, isolate cameras from untrusted networks, enforce least privilege, and deploy network-level controls and logging.

Vulnerability details (non-actionable)

The vulnerability is a classic command-injection flaw in the device web interface where user-supplied HTTP parameters were concatenated into operating-system-level commands without proper sanitization. Because the web interface accepted requests without authentication for certain endpoints, an unauthenticated remote attacker could submit crafted input and cause the device to execute arbitrary shell commands.

From a defensive perspective, important characteristics to monitor for:

• Unauthenticated HTTP POST or GET requests targeting device management endpoints (web root paths used by the device).
• Requests containing control characters and shell metacharacters (for example: semicolons, pipes, backticks) embedded in parameters where numeric or simple values are expected.
• Unexpected outbound connections initiated by the device to infrastructure not under expected management control (reverse-shell-like callbacks or DNS tunnelling).

Vulnerability metadata

Item	Details
CVE	CVE-2022-37061
Affected product	FLIR AX8 (firmware ≤ 1.46.16)
Impact	Unauthenticated remote command execution → full device compromise
Disclosure	Publicly disclosed in 2022

Safe detection and inventory

Before taking any active measures, build an inventory of FLIR AX8 devices on your network and confirm firmware versions. Use passive or non-destructive checks to detect the device version via the web interface banner or device management API.

Example: a safe Python script to query the device's login page and read the version string (this only performs a GET and parses an HTML element; it does not modify the device or send exploit payloads):

#!/usr/bin/env python3
# Safe version-check script (read-only)
import requests
from bs4 import BeautifulSoup

requests.packages.urllib3.disable_warnings()

def get_flir_version(host, port=80, timeout=10):
    url = f'http://{host}:{port}/login/'
    resp = requests.get(url, verify=False, timeout=timeout)
    if resp.status_code != 200:
        return None
    soup = BeautifulSoup(resp.text, 'html.parser')
    title = soup.find('p', id='login-title')
    return title.string.strip() if title else None

if __name__ == '__main__':
    host = '192.0.2.10'  # replace with target IP in your environment
    v = get_flir_version(host)
    print(f'Device {host} reported version: {v}')

Explanation: This script performs a read-only HTTP GET to the device login path and extracts the version text displayed on the page. It is safe to run against devices you manage and helps identify targets that require firmware updates. Do not use it to probe devices you do not own or have permission to test.

Network-level detection

• Create IDS/IPS signatures that flag HTTP requests to management endpoints containing shell metacharacters in parameters where such characters are not expected.
• Monitor for unusual outbound connections from camera IPs — high-entropy DNS, long-lived TCP connections to uncommon ports, or new TLS endpoints.
• Collect full HTTP request logs (web proxy or network tap) from networks hosting cameras and search for anomalies in POST bodies to device endpoints.

Example SIEM query concept (search for suspicious characters in POST bodies):

# Pseudocode/logic for log search (adapt to your SIEM)
index=network_logs method=POST uri="/res.php" | where request_body matches /[;&|`$()]/

Explanation: The example shows the concept of filtering HTTP POST requests that include characters often used in shell injection. Implement and tune similar queries in your SIEM, accounting for false positives.

Mitigation and hardening

Prioritize applying vendor-supplied patches. If an immediate patch is not possible, apply the following compensating controls:

• Firmware update: Apply the FLIR firmware update that fixes the vulnerability. Check FLIR support advisories for the exact version and release notes.
• Network segmentation: Place cameras on a dedicated management VLAN and block direct access from untrusted networks, including the Internet.
• Firewall/ACLs: Restrict access to camera management ports to a small set of trusted IPs (management workstations, automation controllers).
• Disable unused services: Turn off remote services or features not required in your environment (remote HTTP, Telnet, FTP, etc.).
• WAF / web request filtering: Configure a web application firewall to drop or sanitize requests with suspicious characters in parameters to the camera web interface.
• Credential hygiene: Ensure unique, strong credentials are used and change any factory defaults. Use certificate-based management or VPN-based access where possible.
• Monitoring: Enable and centralize logging from cameras and nearby infrastructure, and alert on unusual behavior.

Example defensive ModSecurity rule to block requests with obvious shell characters (illustrative; test before deploying):

# ModSecurity example (illustrative only)
SecRule REQUEST_URI "@contains /res.php" "phase:1,deny,log,id:10001,msg:'Block potential command-injection attempt against res.php'"
SecRule ARGS_NAMES|ARGS|REQUEST_BODY "@rx [;&|`$()]" "phase:2,deny,log,id:10002,msg:'Blocked potential shell-metacharacter in request'"

Explanation: The ModSecurity snippet demonstrates defensive blocking rules that deny requests to a specific URI and block if request parameters contain typical shell metacharacters. This is a compensating control and should be tuned to your environment to avoid false positives.

Incident response (if compromise is suspected)

• Isolate the device from the network immediately — move it to a quarantine VLAN and disable remote management interfaces.
• Preserve forensic evidence: capture the device filesystem if possible, collect network logs, and snapshot any supporting controllers.
• Look for indicators of compromise: new user accounts, scheduled tasks, modified binaries, outbound connections to unknown IPs, and persisted reverse shells.
• Reimage or replace compromised devices; do not trust a factory reset alone if persistence mechanisms are unknown.
• Rotate any credentials that may have been exposed and audit related systems for lateral movement.

Responsible disclosure and vendor coordination

If you discover devices in your environment that appear vulnerable or compromised, coordinate with FLIR support and follow your organization's disclosure and incident handling processes. Provide logs and reproducible, non-actionable findings to the vendor and request guidance and firmware fixes. For external researchers, follow responsible disclosure best practices: avoid publishing exploit code or step-by-step instructions that enable attackers, provide the vendor reasonable time to patch, and share remediation information with affected users.

Expert tips and long-term recommendations

• Treat OT/IoT devices (including cameras) as full-fledged endpoints: maintain inventory, patch schedules, and dedicated monitoring.
• Prefer management over secure channels (VPNs, isolated management networks) rather than exposing web UIs to general-purpose networks or the Internet.
• Use threat intelligence and vendor advisories to stay current on new CVEs affecting device families in your estate.
• Adopt defense-in-depth: even with vendor patches, layering network controls, WAF, and logging reduces the window of exposure.

Further reading and vendor resources

• FLIR product pages and support portal — check for firmware advisories and release notes.
• CVE-2022-37061 tracking pages and public advisories from coordinated vulnerability databases.
• Guidance on securing IoT and OT devices from NIST and industry bodies (best practices for network segmentation, monitoring, and patch management).

Note: The technical description above is intended for defenders, system owners, and incident responders. Do not use the details in this article to attack systems you do not own or have explicit authorization to test. If you need assistance performing authorized security assessments or remediation for FLIR AX8 devices in your environment, engage qualified professionals and follow legal and ethical testing frameworks.