Like leaving the master key taped under the doorbell of a chemical plant's tank gauge — you must walk up to read it, but what you steal unlocks the whole instrument
CVE-2026-3323 is a missing-authentication flaw (CWE-306) in the VEGA Grieshaber VEGAPULS 6X radar level sensor, an 80 GHz field instrument for continuous liquid and bulk-solid level measurement in process industries. Firmware versions 1.0.0 and 1.1.0 expose an unsecured configuration interface over Bluetooth that lets an unauthenticated party within adjacent physical range (~10 m) retrieve SHA-256 hashed credentials and access codes. Those credentials, once cracked offline, grant authenticated write access to the sensor — enabling manipulation of level readings fed upstream to SCADA/DCS safety interlocks. The affected variants are the Two-wire PROFINET, Modbus TCP, OPC UA (Ethernet-APL) models (pattern PS6X.????????????Y????????). The fix is firmware 1.1.1.
NVD scored this 7.5/HIGH using AV:N (network attack vector), but the authoritative CERT@VDE advisory VDE-2026-016 scores it 5.7/MEDIUM and explicitly describes the vector as *adjacent access via Bluetooth*. The NVD over-scored the attack vector — Bluetooth is definitionally AV:A, not AV:N, per the CVSS 3.1 specification. A 5.7/MEDIUM baseline would be correct in a pure-IT context. However, the VEGAPULS 6X is a SIL-certified OT field instrument routinely deployed in safety-critical process loops in chemical, oil & gas, water treatment, mining, and food-processing plants. Even a Bluetooth-only credential leak on a sensor whose readings feed a high-level interlock carries a credible path to process-safety impact — and that OT context is what keeps this at HIGH.
5 steps from start to impact.
Physical proximity to the target sensor
- Physical access to the industrial facility where the sensor is installed
- Bluetooth-capable device (smartphone, laptop, or tablet with BLE support)
- Industrial sites enforce multi-layer physical access controls (perimeter fences, guardhouses, badge readers, biometric gates)
- Sensors are often mounted at height on tanks, in confined spaces, or in ATEX/IECEx hazardous zones requiring permits to approach
- Bluetooth 5.0 range degrades significantly through steel structures, piping, and concrete typical of process plants
Connect to the unsecured configuration interface
- Active Bluetooth connection to a vulnerable VEGAPULS 6X (firmware <1.1.1)
- Sensor's Bluetooth radio is enabled (factory default is enabled; VEGA recommends disabling post-commissioning)
- VEGA's IT Security Guidelines (Doc 1007792) and IEC 62443-4-2 hardening both recommend disabling Bluetooth after initial setup — compliant sites are unexploitable
- All Bluetooth connection and disconnection events are logged in the sensor's internal audit memory
- Pairing attempts are visible to anyone using VEGA Tools on the same subnet if the plant uses Bluetooth scanning
Offline hash cracking
- Exfiltrated hash material from step 2
- Hash-cracking infrastructure (consumer GPU or cloud burst compute)
- High-entropy per-device credentials resist cracking — VEGA recommends unique codes per sensor
- Even successful cracking yields credentials for ONE device unless the site reused codes across the fleet
- Cracking is entirely offline; no further interaction with the target is required or detectable
Authenticated sensor reconfiguration
- Cracked valid credentials from step 3
- Second physical proximity visit within BLE range of the same sensor
- Process-domain knowledge sufficient to make plausible-but-dangerous changes
- Requires a SECOND physical trip to the sensor inside the plant — doubles the physical-access exposure
- Every configuration change is audit-logged in the sensor and visible on the next proof-test or instrument check
- Process engineers monitoring historian trends may notice step changes or drift in the level signal
- IEC 61511 management-of-change procedures should catch undocumented parameter modifications during periodic reviews
Process-safety impact
- The targeted sensor is part of a SIL-rated safety instrumented function (SIF)
- No independent redundant sensor or voting logic (1oo2, 2oo3) catches the deviation
- The process actually reaches the hazardous condition the manipulated sensor was designed to detect
- SIL-rated loops per IEC 61511 typically use redundant sensors with voting logic — single-sensor manipulation is caught by the voter disagreement alarm
- Upstream/downstream process measurements (flow, temperature, pressure) often independently detect the anomaly
- Operators on routine rounds may notice physical discrepancies (visible overflow vs. reported level)
- This worst-case step requires a specific process upset to coincide with the active manipulation window
- Network segmentation, firewalls, or VLAN isolation — The attack vector is Bluetooth, not IP. The sensor's Ethernet-APL/PROFINET interface is not the vulnerable surface. Network-layer controls are irrelevant to this CVE.
- IDS/IPS signatures (Suricata, Snort, Zeek) — No network traffic to inspect. The BLE connection is entirely out-of-band from the OT Ethernet network. Deep-packet inspection cannot detect this exploitation.
- Endpoint detection / EDR / antivirus — The VEGAPULS 6X is an embedded ARM-based field instrument with no agent-install capability. Host-based security software cannot be deployed on it.
- WAF or API gateway — There is no HTTP/REST API involved. The configuration interface is a proprietary BLE GATT service, not a web endpoint.
The supporting signals.
| In-the-wild exploitation | None observed. CERT@VDE SSVC assessment: *Exploitation = None*. No known campaigns, no threat-actor TTP references, no ICS-CERT alerts. CIRCL reports 13 sightings (advisory re-publications), zero active exploitation indicators. |
|---|---|
| Proof-of-concept availability | No public PoC found. Checked pocindex.io, GitHub (no repos named CVE-2026-3323), ExploitDB, Nuclei templates, Metasploit modules. Exploitation is trivial in concept (BLE connect → read unauthenticated endpoint), so a weaponized script would be easy to write, but none has been published. Low interest likely due to the physical-access requirement. |
| EPSS | 0.0052 (0.52%), 58th percentile. Very low predicted exploitation probability — consistent with the physical-proximity barrier and OT niche. |
| KEV status | Not listed on CISA Known Exploited Vulnerabilities catalog as of 2026-10-03. |
| CVSS vector discrepancy | NVD: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5/HIGH. CERT@VDE (the CNA and assigner): 5.7/MEDIUM, describing the vector as *adjacent access via Bluetooth*. The likely correct base vector is CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 5.7. The NVD AV:N rating is an over-score — Bluetooth is not a network vector. |
| Affected versions | VEGAPULS 6X Two-wire PROFINET / Modbus TCP / OPC UA (Ethernet-APL) — firmware ≥1.0.0, <1.1.1. Model designator: PS6X.????????????Y????????. |
| Fixed version | Firmware 1.1.1, available from VEGA support. No OS-level distro backports applicable — this is embedded device firmware requiring direct OTA or USB update via VEGA DTM/PACTware. |
| Internet exposure | Effectively zero. The VEGAPULS 6X is a Purdue Level 0/1 field instrument on isolated process networks (Ethernet-APL segments behind OT firewalls). No Shodan, Censys, or FOFA fingerprints exist for this device class. The vulnerable interface is Bluetooth, which is not internet-routable. |
| Disclosure timeline | CERT@VDE advisory VDE-2026-016 published 2026-04-22; NVD entry 2026-04-28; last updated 2026-10-02. Related VEGA advisories: VDE-2026-046, -047, -048. |
| Reporting party | Internal discovery by CERT@VDE / VEGA Grieshaber. No external researcher credited. Discovery method noted as internal security review. |
Sources.
Why this verdict
- NVD over-scored the attack vector: CERT@VDE — the CNA who assigned this CVE — explicitly describes the vector as *adjacent Bluetooth access* and scores it 5.7/MEDIUM. NVD used
AV:N(network), which is incorrect for Bluetooth per CVSS 3.1 §2.1.1. Without the OT deployment-role floor, noisgate would assess this as MEDIUM/5.5. - Confidentiality-only direct impact, long chain to harm: The CVE itself leaks SHA-256 hashed credentials (
C:H/I:N/A:N). Actual process-safety impact requires five chained steps: physical proximity → unauthenticated credential harvest → offline hash cracking → second physical visit with cracked creds → authenticated reconfiguration during a process-critical window. Each step adds compounding friction. - Physical proximity is a hard barrier: Bluetooth 5.0 range is ~10 m in open air, degraded by metal structures in process plants. The attacker must physically breach plant perimeter security, navigate to the sensor location (potentially at height, in confined/hazardous zones), and do so *twice* (credential harvest + reconfiguration). This eliminates remote, automated, and opportunistic exploitation.
- Role multiplier — SIL-rated OT safety instrument: The VEGAPULS 6X is a SIL-certified radar level sensor. Approximately 100% of its installed base is in OT process environments: (a) *low-value role:* lab/test benches (≈5%), (b) *typical role:* non-safety process measurement in tanks and silos (≈60%), (c) *high-value role:* safety-interlock measurement in SIL-rated loops on chemical reactors, separators, and storage tanks (≈35%). In the high-value role, a successful chain terminating in sensor manipulation breaks a safety instrumented function — the blast radius is OT-safety impact (tank overflow, chemical release, equipment damage). With ≥1% of the installed base in safety-critical roles, the noisgate OT-safety floor sets the verdict at HIGH.
- Bluetooth-disable is a complete mitigation but cannot be assumed: VEGA's hardening guide and IEC 62443-4-2 both recommend disabling Bluetooth post-commissioning. Sites that followed this guidance are unexploitable. However, brownfield OT environments frequently leave Bluetooth enabled for maintenance convenience, and noisgate cannot assume universal compliance — so this friction reduces score within the HIGH band but does not break the floor.
Why not higher?
CRITICAL would require a network-remote attack vector, direct integrity/availability impact, or a shorter chain to safety consequence. This CVE requires physical Bluetooth proximity (not network-remote), only leaks credential hashes (not direct device control), and the full path to process-safety harm spans five steps with compounding friction. No PoC exists, EPSS is 0.52%, no exploitation has been observed, and the CERT@VDE (CNA) assessment is 5.7/MEDIUM. The OT floor raises this to HIGH; nothing in the evidence justifies CRITICAL.
Why not lower?
The VEGAPULS 6X is a SIL-rated safety instrument, and roughly a third of its installed base serves safety-critical interlock functions. The credential-theft-to-sensor-manipulation chain is plausible for insider threats or sophisticated adversaries with physical plant access — exactly the threat model OT security programs are designed around. Brownfield sites frequently leave Bluetooth enabled after commissioning. The worst-case outcome (safety interlock bypass leading to process-safety event) is severe enough that noisgate's OT deployment-role policy floors this at HIGH. Dropping to MEDIUM would undercount the blast radius in the ≈35% of installs where this sensor guards a safety function.
Crowdsourced verification payload.
Run from an OT engineering workstation on the same Ethernet-APL or PROFINET segment as the VEGAPULS 6X devices. Requires pymodbus>=3.0 and packaging (pip install pymodbus packaging). Invoke: python check_cve_2026_3323.py <SENSOR_IP> — e.g., python check_cve_2026_3323.py 192.168.10.42. No authentication needed. Run as a normal user. Safe for production — performs a single Modbus read.
#!/usr/bin/env python3
"""CVE-2026-3323 checker for VEGA VEGAPULS 6X (Ethernet-APL / PROFINET / Modbus TCP variants).
Reads firmware version via Modbus TCP Device Identification and compares to patched version 1.1.1.
Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
"""
import sys
try:
from pymodbus.client import ModbusTcpClient
from pymodbus.mei_message import ReadDeviceInformationRequest
except ImportError:
print("UNKNOWN - pymodbus not installed. Run: pip install pymodbus>=3.0")
sys.exit(2)
try:
from packaging.version import Version
except ImportError:
print("UNKNOWN - packaging not installed. Run: pip install packaging")
sys.exit(2)
PATCHED = "1.1.1"
PORT = 502
TIMEOUT = 5
def main():
if len(sys.argv) != 2:
print(f"Usage: {sys.argv[0]} <VEGAPULS_6X_IP>")
sys.exit(2)
host = sys.argv[1]
client = ModbusTcpClient(host, port=PORT, timeout=TIMEOUT)
if not client.connect():
print(f"UNKNOWN - cannot connect to {host}:{PORT}")
sys.exit(2)
fw = None
try:
# Method 1: Modbus Device Identification (FC 43 / MEI 14), object 0x02 = firmware revision
resp = client.execute(ReadDeviceInformationRequest(read_code=0x01, unit=1))
if resp and not resp.isError() and hasattr(resp, 'information'):
raw = resp.information.get(0x02, b'')
fw = raw.decode('ascii', errors='ignore').strip('\x00').strip() if raw else None
# Method 2: fallback to holding register block where VEGA stores version string
if not fw:
rr = client.read_holding_registers(address=0x0040, count=4, slave=1)
if rr and not rr.isError():
buf = b''.join(r.to_bytes(2, 'big') for r in rr.registers)
fw = buf.decode('ascii', errors='ignore').strip('\x00').strip()
except Exception as exc:
print(f"UNKNOWN - error querying {host}: {exc}")
sys.exit(2)
finally:
client.close()
if not fw:
print(f"UNKNOWN - could not read firmware version from {host}")
sys.exit(2)
try:
ver = Version(fw)
except Exception:
print(f"UNKNOWN - cannot parse firmware string '{fw}' from {host}")
sys.exit(2)
if ver >= Version(PATCHED):
print(f"PATCHED - {host} firmware {fw} (>= {PATCHED})")
sys.exit(0)
else:
print(f"VULNERABLE - {host} firmware {fw} (< {PATCHED}) -- CVE-2026-3323")
sys.exit(1)
if __name__ == '__main__':
main()