CVE-2026-42806

Executive Summary

CVE-2026-42806 is an out-of-bounds read vulnerability in the Bosch BME690 SensorAPI C-driver (bme69x.c), present in version v1.0.3 and all prior releases. The defect resides in the field data parsing path of read_all_field_data, where a 4-bit gas_index field (values 0–15) is used to index a 30-byte stack buffer (set_val) without validating it against the documented valid range of 0–9, allowing an out-of-bounds read of up to 6 bytes past the buffer.

Because the sensor communicates over an I2C/SPI bus, the attack requires physical or bus-level access — an attacker, or a compromised peripheral that electrically mimics a BME690 sensor, can return a crafted payload that drives the index out of bounds. The leaked stack byte is written into the public gas_wait field and may be telemetered or logged, resulting in adjacent stack memory disclosure and possible measurement corruption.

The CVSS v3.1 base score is 4.3 (Medium) with vector CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. There is no public proof-of-concept, no Nuclei template, no vendor patch, and the CVE is not listed in CISA KEV. Despite the modest score, embedded and IoT deployments that treat the sensor bus as trusted are the primary at-risk population.

Technical Analysis

The BME690 is a multi-gas/environmental sensor from Bosch Sensortec. The C reference driver (bme69x.c) implements the host-side logic for configuring the device and reading field measurement data. A relevant code path is read_all_field_data, which orchestrates the parsing of the sensor's field data payloads.

During driver initialization, heater configuration registers are prefetched into a contiguous 30-byte stack-allocated buffer named set_val. This buffer maps the device's heater-related tables — IDAC, RES_HEAT, and GAS_WAIT. The layout means that indices 0–9 in the GAS_WAIT table are the only legitimately addressable entries; the remaining bytes serve the IDAC and RES_HEAT tables.

When read_all_field_data parses incoming measurement data, it extracts the gas_index from the payload using a 4-bit mask. A 4-bit mask can represent values 0 through 15, but no validation is performed against the valid range of 0 through 9. The driver then computes the array access:

set_val[20 + gas_index]

With gas_index values of 10 through 15, this expression addresses set_val[30] through set_val[35], reading up to 6 bytes past the end of the 30-byte stack buffer.

Root Cause

The root cause is a classic CWE-125 out-of-bounds read — a missing bounds check on an externally supplied, protocol-driven index. The trust boundary is improperly placed: the driver assumes the sensor peripheral is honest and returns only well-formed gas_index values. Because I2C and SPI are electrically exposed buses, that assumption is unsafe in adversarial or physically compromised environments.

Attack Surface

The attack surface is the sensor bus itself:

• I2C: multi-drop bus; any device that can drive the SDA/SCL lines or spoof the sensor's 7-bit address can inject a crafted field data payload.
• SPI: point-to-point, but a compromised or swapped peripheral, malicious interposer, or debug probe can emulate the sensor.

Because the vulnerability is triggered during field data parsing (read_all_field_data), any application that regularly polls the sensor (continuous gas measurement, environmental monitoring, wearable or industrial telemetry) will exercise the vulnerable code path repeatedly.

Data Flow of the Leak

1. Driver prefetches 30 bytes of heater configuration into set_val.
2. Sensor responds with field data containing a gas_index.
3. Driver masks four bits → gas_index ∈ [0,15].
4. Access set_val[20 + gas_index] reads out of bounds for gas_index ≥ 10.
5. The out-of-bounds byte is stored into the public gas_wait field.
6. Whatever consumes gas_wait — logging, telemetry uplink, host application — may receive the leaked byte.

The leaked memory is adjacent stack data. It is not attacker-controlled in content, but its disclosure can reveal pointers, locals, or other sensitive driver state depending on stack layout at the time of the read.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template exists for CVE-2026-42806. The attack chain below is inferred from the vulnerability class (out-of-bounds read on a protocol-supplied index) and the specific mechanism documented in the NVD description. No function names, endpoints, or parameters beyond those in the advisory are asserted.

1) Reconnaissance / Target Identification An adversary identifies a target platform whose firmware links the Bosch BME690 C driver (v1.0.3 or earlier) and which communicates with the sensor over I2C or SPI. Identifying such devices requires knowledge of the BOM/firmware — obtainable from teardowns, firmware dumps, or public datasheets/BSP repos — or physical access to the target hardware. This is a physical-adjacent attack (AV:P), so logical remote reconnaissance is limited; the practical precondition is bus-level access.

2) Triggering the Flaw Class The attacker (or a malicious peripheral) places itself on the sensor bus — e.g., via an interposer, compromised replacement sensor, or debug interface — and impersonates the BME690. When the driver issues the field data read, the malicious device responds with a payload containing a gas_index of 10 or greater. Because the driver masks only 4 bits and never verifies the value against the valid 0–9 range, the check is bypassed by design.

3) Payload / Execution Method The malicious payload is a legitimate-looking sensor field-data response whose gas_index nibble is set to 10–15. The driver then executes set_val[20 + gas_index] and reads 0–6 bytes past the 30-byte stack buffer. No code execution is required — the flaw is a read, and the "payload" is simply the poisoned index value delivered over the bus protocol.

4) Post-Exploitation Impact The out-of-bounds byte is written into the public gas_wait field. If the host application logs, transmits, or otherwise exposes gas_wait, adjacent stack memory is disclosed. Secondary consequences per the advisory: corrupted gas-wait measurements (integrity loss) and memory disclosure (confidentiality loss). In embedded telemetry contexts, that leaked byte can be exfiltrated off-device by whatever routine ships sensor readings upstream. There is no documented path to code execution from this read alone.

Impact Assessment

CVSS v3.1: 4.3 (Medium) — CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

• AV:P (Physical): exploitation requires access to the I2C/SPI bus — physical proximity or a compromised peripheral. This constrains the threat to attackers with hardware access, malicious supply chain insertion of a fake sensor, or an on-device foothold on the bus.
• AC:L (Low): no special conditions beyond bus access; the malformed index is trivially generated.
• PR:N / UI:N: no authentication or user interaction.
• S:U (Unchanged): impact is confined to the driver's security scope.
• C:L / I:L / A:L: low confidentiality (up to a few bytes of adjacent stack), low integrity (corrupted measurements, gas_wait field poisoning), low availability (no crash/DoS documented, but corrupted field handling could disrupt consumers).

Blast radius: Any product embedding the BME690 C driver version ≤ v1.0.3 and polling field data over I2C/SPI. This includes wearables, environmental monitoring stations, industrial IoT sensor nodes, air-quality monitors, and consumer gadgets using Bosch's reference driver. Because it ships as source/C reference code, the affected population spans many downstream vendors who integrate it into their firmware — a broad but shallow impact surface.

Business impact: Low-to-moderate per device. Memory disclosure of a few stack bytes is rarely catastrophic on its own, but in safety-relevant or privacy-sensitive deployments (health, environmental compliance data), measurement corruption and information leakage can undermine data integrity guarantees, invite regulatory scrutiny, and complicate supply-chain trust. For vendors, it represents an unpatched liability in shipped firmware.

Detection Guidance

Detection for a physical-bus vulnerability is inherently limited — there is no network exploit packet. The following rules target the observable artifacts: firmware/binary presence of the vulnerable driver, anomalous gas index values appearing in telemetry or logs, and host-side integrity monitoring.

Sigma Rule

title: Potential Bosch BME690 Out-of-Bounds Read via Malicious Gas Index
id: 7c2f9b41-4280-6a01-b690-cec12542806a
status: experimental
description: Detects application logs or telemetry indicating a gas_index value outside the valid 0-9 range in Bosch BME690 driver output, which may indicate CVE-2026-42806 exploitation via a malicious sensor on the I2C/SPI bus.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-42806
author: valtersit.com
date: 2026/01/15
tags:
  - attack.t1195
  - cve.2026.42806
logsource:
  category: application
  product: embedded
detection:
  selection_msg:
    - 'gas_index'
    - 'gas_wait'
  selection_value:
    gas_index: 10|11|12|13|14|15
  condition: selection_msg and selection_value
falsepositives:
  - Legitimate driver updates that add new valid gas index entries
  - Debug tooling that intentionally sets out-of-range values
level: medium

YARA Rule

rule CVE_2026_42806_BME690_OOB_Read
{
    meta:
        description = "Identifies firmware/binaries linking vulnerable Bosch BME690 SensorAPI (bme69x.c) <= v1.0.3 around read_all_field_data field parsing"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-42806"
        cve = "CVE-2026-42806"
        date = "2026-01-15"

    strings:
        $fn1 = "read_all_field_data" ascii
        $sym1 = "bme69x" ascii nocase
        $sym2 = "set_val" ascii
        $sym3 = "gas_index" ascii
        $sym4 = "gas_wait" ascii
        $sym5 = "RES_HEAT" ascii
        $sym6 = "GAS_WAIT" ascii
        $ver  = "1.0.3" ascii

    condition:
        (uint16(0) == 0x5A4D or uint32(0) == 0x464C457F) and
        $fn1 and
        2 of ($sym1, $sym2, $sym3, $sym4, $sym5, $sym6)
}

Suricata IDS Rule

Because exploitation is on a local I2C/SPI bus, network visibility is indirect. This rule flags telemetry uplinks that carry BME690 gas-wait fields reporting out-of-range gas indexes — a plausible post-exploitation disclosure channel.

alert http any any -> any any (msg:"CVE-2026-42806 Bosch BME690 Suspected Gas Index Out-of-Bounds in Telemetry"; flow:to_server,established; content:"gas_index"; nocase; http_client_body; pcre:"/gas_index\"?\s*[:=]\s*\"?(1[0-5])\b/i"; reference:cve,2026-42806; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-42806; classtype:attempted-recon; sid:2026042806; rev:1;)

A generic MQTT variant can be used for deployments that publish sensor readings over MQTT:

alert tcp any any -> any 1883 (msg:"CVE-2026-42806 BME690 Out-of-Range Gas Index over MQTT"; flow:to_server,established; content:"gas_index"; nocase; pcre:"/gas_index\"?\s*[:=]\s*\"?(1[0-5])\b/i"; reference:cve,2026-42806; classtype:attempted-recon; sid:2026042807; rev:1;)

Elastic Detection

sequence by host.id with maxspan=5m
  [ process where process.name != null and
      process.command_line : "*bme69*" ]
  [ any where
      ( wildcard(process.args, "*gas_index*") or wildcard(process.args, "*gas_wait*") ) and
      ( process.args : "*gas_index=1*" ) ]

For environments that ingest structured sensor telemetry, a simpler threshold rule is appropriate:

sensor.gas_index >= 10 and sensor.gas_index <= 15

This fires when any host reports a BME690 gas_index outside the documented valid range — the direct observable of CVE-2026-42806.

Splunk SPL Query

index=embedded OR index=iot OR index=telemetry (source="*bme69*" OR source="*bme690*" OR "gas_index" OR "gas_wait")
| eval gi=coalesce(gas_index, field1, gasindex)
| where isnum(gi) AND gi >= 10 AND gi <= 15
| stats count min(_time) as firstSeen max(_time) as lastSeen by host, source, gi
| where count > 0
| convert ctime(firstSeen) ctime(lastSeen)
| sort - count

This query surfaces hosts whose BME690 telemetry contains out-of-range gas indexes, the primary downstream indicator of successful exploitation.

Wazuh OSSEC Rule

<group name="bosch,bme690,cve-2026-42806,">
  <rule id="20260428" level="10">
    <decoded_as>bme690</decoded_as>
    <match>gas_index</match>
    <regex>gas_index[\"'\s:=]+1[0-5]\b</regex>
    <description>CVE-2026-42806: Bosch BME690 out-of-range gas_index detected - possible OOB read via malicious sensor</description>
    <mitre>
      <id>T1195</id>
    </mitre>
    <group>cve_2026_42806,embedded,physical_access,</group>
  </rule>

  <rule id="20260429" level="8">
    <decoded_as>bme690</decoded_as>
    <match>gas_wait</match>
    <regex>gas_wait[\"'\s:=]+0x</regex>
    <description>CVE-2026-42806: Bosch BME690 gas_wait field populated - possible stack memory disclosure artifact</description>
    <group>cve_2026_42806,embedded,data_leak,</group>
  </rule>
</group>

A companion ossec.conf decoder should extract gas_index and gas_wait from the driver's log lines for these rules to fire on structured content.

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No tracked source provides patch evidence; the vendor has published no fixed release. v1.0.3 and all prior versions remain affected.

1) Immediate Mitigations

• Enforce index validation upstream of the buffer access. Because the driver itself does not bound-check, integrators who compile the reference source can insert a guard in read_all_field_data: reject or clamp any gas_index value outside the documented 0–9 range before it is used to index set_val. This is the single most effective mitigation and closes the vulnerability class entirely.
• Treat the sensor bus as an untrusted input channel. Validate all sensor-provided fields at the protocol-parse boundary, not only at the point of use.
• Suppress or sandbox logging of gas_wait where it may carry leaked stack bytes to external telemetry. If the value must be logged, cap/normalize it.
• Physical hardening: disable or lock debug interfaces (JTAG/SWD), consider authenticated sensor busses where supported, and adopt tamper-evident enclosures to raise the cost of interposer-style attacks (aligned with AV:P).
• Supply-chain controls: source BME690 sensors and replacement peripherals only from verified suppliers with traceability, to reduce the risk of a malicious peripheral impersonating the sensor.

2) Patch / Upgrade Steps

• No fixed version exists. Monitor Bosch Sensortec's BME690 GitHub repository and product advisories for a patched driver release.
• Where a fixed release lands, upgrade the linked bme69x.c to the patched version, rebuild firmware, and redeploy.
• If the vendor remains silent, escalate through your component supply relationship; unpatched upstream reference drivers are a recurring liability.

3) Long-Term Hardening

• Adopt a defense-in-depth parsing model: all externally sourced fields — especially those crossing a hardware bus — must be range-validated before use as array indexes, lengths, or buffer offsets.
• Fuzz the sensor interface: hardware-in-the-loop fuzzing of the I2C/SPI protocol handler can systematically surface this class of bug (index validation, length fields, table lookups) before production.
• Static analysis in CI: enable CWE-125/CWE-129 taint analysis across the driver to catch externally influenced array indexes.
• Threat-model the bus boundary: document I2C/SPI peripheral impersonation as an explicit threat in product security requirements.

References

1. NVD — CVE-2026-42806: https://nvd.nist.gov/vuln/detail/CVE-2026-42806
2. MITRE CWE-125 — Out-of-bounds Read: https://cwe.mitre.org/data/definitions/125.html
3. CVE.org record for CVE-2026-42806: https://www.cve.org/CVERecord?id=CVE-2026-42806
4. Bosch Sensortec BME690 product and driver resources: https://www.bosch-sensortec.com/products/environmental-sensors/gas-sensors/bme690/ (verify driver repository and advisories directly)
5. FIRST.org EPSS: Not yet scored — no EPSS value available for this CVE.

Threat actor / exploit-in-the-wild evidence: None observed. CVE-2026-42806 is not in CISA KEV, has no public PoC, no Nuclei template, and no tracked exploit code. The attack chain described in this report is inferred from the vulnerability class and the NVD advisory, not from observed exploitation.