230,000 Smart Grills, Zero Authentication: Inside the Flame Boss / BBQ Guru API Exposure

PublishedMarch 15, 2026

iotidorapi-securitymqttresponsible-disclosurebbq-guruflame-boss

TL;DR

The ShareMyCook.com REST API — the cloud backend for both BBQ Guru and Flame Boss WiFi-connected temperature controllers — exposes every registered device's configuration, hardware identifiers, and cook session data to anyone on the internet without authentication. Sequential integer IDs allow trivial enumeration of the entire database: an estimated 230,000 devices, roughly 8,500 of which remain actively connected. The API also leaks MQTT broker credentials that could enable remote device control. No CVE has been assigned. No prior security research on these platforms exists.

Background

BBQ Guru and Flame Boss manufacture WiFi-enabled PID temperature controllers for charcoal grills and smokers. The devices regulate pit temperature by controlling a blower fan based on thermocouple readings. Both brands were unified under Collins Research Inc. following BBQ Guru's acquisition by Flame Boss in 2022, and both share a single cloud platform: ShareMyCook.com, which is a white-labeled deployment of MyFlameBoss.com.

The BBQ Guru UltraQ and Flame Boss 500 connect to WiFi and communicate outbound to the cloud via MQTT (s2.myflameboss.com:8883). Users monitor and control their cooks through a mobile app that talks to the same cloud backend. The devices expose no local network services — all 65,535 TCP ports are closed or filtered. The entire attack surface is the cloud API.

Discovery

This research began with a simple question: does my BBQ Guru UltraQ expose a local API on my home network? After a full nmap scan confirmed zero open ports, attention shifted to the cloud backend at ShareMyCook.com.

A basic endpoint enumeration revealed three API routes returning HTTP 200 without any authentication:

GET /api/v1/devices/{id}
GET /api/v1/cooks/{id}
GET /api/v2/devices

Finding 1: Unauthenticated Device Enumeration (IDOR)

Device IDs are sequential integers starting from 1. No authentication token, session cookie, or API key is required. A simple GET request returns the full device record:

GET https://sharemycook.com/api/v1/devices/10000

{
  "alarm": false,
  "boot_ver": 33619969,
  "celsius": false,
  "fw_ver": 68747292,
  "hw_id": 3,
  "id": 10000,
  "local_access": 2,
  "mcu_uid": "AAC8gycAQXoIADYARU5SMw==",
  "meat_alarms": [1, 0, 0, 488, 905, 905, 933],
  "mqtt": true,
  "mqtt_host": "s2.myflameboss.com",
  "mqtt_port": 8883,
  "mqtt_tls": true,
  "name": "Controller 10000",
  "online": false,
  "set_temp": 1583,
  "sn": null,
  "sta_mac": "60:01:94:08:77:59",
  "most_recent_cook": {
    "id": 4309871,
    "device_name": "Controller 10000",
    "created_at": "2024-11-28T05:44:09.000Z",
    "ended_at": "2024-11-28T18:43:59.000Z",
    "private": false
  }
}

Every device record includes:

Field	Sensitivity	Description
`sta_mac`	Device identifier	WiFi MAC address
`mcu_uid`	Hardware fingerprint	Base64-encoded microcontroller unique ID
`sn`	Serial number	Manufacturing serial number
`mqtt_host`, `mqtt_port`	Infrastructure	MQTT broker connection details
`fw_ver`, `hw_id`, `boot_ver`	Firmware intel	Enables targeted exploit development
`set_temp`, `meat_alarms`, `pit_alarm`	Cook state	Current temperature configuration
`online`	Status	Whether device is actively connected
`most_recent_cook`	Usage data	Last cook session metadata

Finding 2: Unauthenticated Cook Session Data

Cook session IDs are discoverable via the most_recent_cook.id field in device responses. Each cook record contains the complete temperature timeseries:

GET https://sharemycook.com/api/v1/cooks/4309871

{
  "created_at": "2024-11-28T05:44:09.000Z",
  "ended_at": "2024-11-28T18:43:59.000Z",
  "device_name": "Controller 10000",
  "private": false,
  "data": [
    {
      "sec": 1732772664,
      "set_temp": 1583,
      "pit_temp": 478,
      "meat_temp1": 320,
      "fan_dc": 45
    }
  ]
}

The private field exists but is meaningless — the API serves all cook data regardless of the privacy setting.

Finding 3: MQTT Broker Credentials

Every device response includes MQTT connection parameters: s2.myflameboss.com on port 8883 with TLS. Flame Boss's own documentation confirms MQTT authentication uses T-{user_id} as the username and the user's auth_token as the password. While the auth token isn't directly exposed in the device endpoint, the combination of known broker address, device identifiers (MCU UID, serial, MAC), and the documented authentication scheme significantly reduces the barrier to unauthorized device control.

If an attacker could authenticate to the MQTT broker, they could potentially:

Subscribe to any device's telemetry feed
Publish temperature setpoint changes to another user's grill
Disable fan control during an active cook

This represents a physical safety concern — an unattended grill pushed to maximum temperature could cause a fire.

Scale Assessment

A randomized sampling of 2,000 device IDs across the full ID range (2–300,000) produced the following estimates:

Metric	Value
Database hit rate	76.5%
Estimated total registered devices	~230,000
Active in March 2026	~8,550 (3.7%)
Currently online (Saturday 9:30 PM ET)	0

Hardware Distribution

The MAC address OUI prefixes reveal the hardware evolution of the platform:

OUI	Manufacturer	Count (sample)	Era
`00:00:09`	Microchip (legacy)	31	Gen 1
`5C:CF:7F`	Espressif ESP8266	5	Gen 2
`84:F3:EB`	Espressif ESP8266	21	Gen 2
`2C:3A:E8`	Espressif ESP32	7	Gen 3
`C4:5B:BE`	Espressif ESP32	10	Gen 3
`DE:AD:BE`	Test devices	5	N/A

Ten distinct hw_id values (0–15) map to different hardware revisions across the BBQ Guru and Flame Boss product lines.

Additional Observations

Rails debug errors in production. Sending a malformed POST to /api/v1/sessions returns internal parameter names and framework suggestions — a textbook information leak:

{
  "error": "param is missing or the value is empty: session\nDid you mean?  session\n               action\n               api_version_s\n               controller"
}

IP address reflection. The /api/v1/devices endpoint (without an ID) returns the requester's public IP address without authentication, alongside the internal backend server hostname s2.myflameboss.com.

White-label architecture. ShareMyCook.com and MyFlameBoss.com are the same Rails application. Session cookies are scoped to myflameboss.com, and the API responses are identical on both domains.

WEP on legacy devices. The older BBQ Guru CyberQ WiFi uses WEP40 encryption with a default key of 1234abcdef. WEP was broken in 2001.

Prior Art

No CVEs, security advisories, or public research exists for Flame Boss or BBQ Guru products. The closest comparable work is Bishop Fox's 2024 disclosure on Traeger Grill D2 Wi-Fi Controllers, which found similar issues: insufficient authorization controls enabling remote grill takeover (CVSS 7.1) and a GraphQL API leaking all registered grills (CVSS 4.3).

Remediation Recommendations

Require authentication on /api/v1/devices/{id} and /api/v1/cooks/{id} — these endpoints should return only the authenticated user's own resources
Replace sequential integer IDs with UUIDs to prevent enumeration
Remove MQTT connection details from API responses
Implement authorization checks (ownership validation) on all device and cook endpoints
Disable Rails debug error messages in production
Audit MQTT broker ACLs to ensure topic-level device isolation
Retire WEP support on legacy hardware

Timeline

Date	Event
2026-03-14	Vulnerability discovered during authorized testing of own device
2026-03-15	Vendor notified via email (info@flameboss.com, customerservice@thebbqguru.com)
2026-03-15	Public disclosure

Research conducted by BreakGlass Intelligence. All testing performed against the researcher's own device and publicly accessible API endpoints. No data was modified, no authentication was bypassed, and no devices beyond the researcher's own were interacted with beyond read-only verification.