← Back to Feed CACHED · 2026-10-02 20:16:53 · CACHE_KEY CVE-2026-3323
CVE-2026-3323 · CWE-306 · Disclosed 2026-04-28

An unsecured configuration interface on affected devices

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Bluetooth-only credential leak on SIL-rated OT sensor — NVD over-scored the vector but OT safety floor holds HIGH"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Physical proximity to the target sensor

The attacker must be within Bluetooth 5.0 range (~10 m line-of-sight, less through metal process structures) of a VEGAPULS 6X running firmware <1.1.1. This means physical presence on the plant floor, tank farm, silo deck, or vessel platform where the sensor is mounted. In virtually all industrial facilities this requires passing perimeter fencing, badge-gated entry points, and often a safety induction.
Conditions required:
  • Physical access to the industrial facility where the sensor is installed
  • Bluetooth-capable device (smartphone, laptop, or tablet with BLE support)
Where this breaks in practice:
  • 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
Detection/coverage: Physical access logs and badge-swipe anomalies; CCTV in process areas; no network-layer detection applies at this stage
STEP 02

Connect to the unsecured configuration interface

The attacker initiates a BLE connection to the VEGAPULS 6X. Due to CVE-2026-3323 the configuration interface does not enforce the Bluetooth access code, allowing the attacker to query it unauthenticated. The interface returns device configuration data including SHA-256 hashed credentials and access codes. No weaponized tooling is needed — VEGA's own free *VEGA Tools* mobile app or any generic BLE scanner (e.g., nRF Connect) suffices.
Conditions required:
  • 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)
Where this breaks in practice:
  • 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
Detection/coverage: Sensor internal event log records every Bluetooth pairing/access event; centralized collection via PROFINET diagnostic channels or OPC UA subscription can surface anomalies if configured
STEP 03

Offline hash cracking

The attacker extracts the SHA-256 hashed credentials and runs them through offline cracking tools — hashcat (mode 1400) or John the Ripper. SHA-256 without salting is susceptible to GPU-accelerated brute force and rainbow-table lookups. Crack time depends on credential entropy: default or short access codes fall in minutes; unique 16+ character randomized codes per VEGA guidance may resist for weeks.
Conditions required:
  • Exfiltrated hash material from step 2
  • Hash-cracking infrastructure (consumer GPU or cloud burst compute)
Where this breaks in practice:
  • 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
Detection/coverage: No on-device or network detection is possible for offline cracking; threat hunting should focus on anomalous Bluetooth connections from step 2
STEP 04

Authenticated sensor reconfiguration

With cracked credentials, the attacker returns to physical Bluetooth range (a second visit) and authenticates to the sensor's full configuration interface. They can now modify zero/span calibration, measurement offsets, damping, alarm thresholds, or linearization curves — causing the sensor to silently report incorrect level values to the SCADA/DCS. All configuration changes are logged in the sensor's non-volatile event memory.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Sensor configuration-change audit log; DCS/SCADA historian trending anomalies; comparison of live readings vs. independent measurements (manual dip, radar gauge, inventory reconciliation)
STEP 05

Process-safety impact

If the manipulated sensor feeds a safety-critical interlock — high-level shutdown on a chemical reactor, overflow protection on a storage tank, or level limit on a separator — false readings could prevent the safety function from actuating when the real process condition demands it. The severity depends on the process role of the specific sensor, the architecture of the Safety Instrumented System (SIS), and whether redundant sensors or diverse measurements are in place.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: SIS diagnostic disagreement alarms; historian trend deviation analytics; operator round observations; independent analytical or manual measurements
03 · Compensating Control

1
HIGH 7.0→IGNORE 0.0
SEVERITY REDUCED
Disable Bluetooth on all VEGAPULS 6X units immediately — This completely eliminates the CVE-2026-3323 attack vector. Bluetooth can be disabled via the sensor's local display menu, VEGA Tools mobile app, or PACTware/DTM over the wired PROFINET/Modbus TCP connection. VEGA's IT Security Guidelines (Document ID 1007792) already recommend this. Walk every unit in the fleet and confirm Bluetooth is off. Deploy within 30 days per the noisgate mitigation SLA for HIGH. This single control reduces the vulnerability to unexploitable.
2
HIGH 7.0→MEDIUM 4.5
SEVERITY REDUCED
Rotate all Bluetooth access codes and device credentials to unique high-entropy values — If default or shared access codes are in use, rotate to unique 16+ character randomized codes per device. This limits the damage from any previously-harvested hashes — cracking one device no longer compromises the fleet. Prioritize sensors in SIL-rated safety loops. Deploy within 30 days. With strong unique credentials, even if an attacker bypasses step 1, hash cracking becomes computationally infeasible for the attack window.
3
HIGH 7.0→IGNORE 0.0
SEVERITY REDUCED
Apply firmware 1.1.1 to all affected VEGAPULS 6X units — The definitive vendor fix. Firmware 1.1.1 restores authentication enforcement on the configuration interface. OT firmware updates require change-management approval (MOC), maintenance-window scheduling, and post-update recalibration verification. Target completion within 180 days per the noisgate remediation SLA for HIGH. Contact VEGA support for the firmware package and release notes.
4
HIGH 7.0→MEDIUM 5.0
SEVERITY REDUCED
Audit SIS architecture for single-sensor dependency on VEGAPULS 6X — Review all Safety Instrumented Functions (SIFs) that use a VEGAPULS 6X as the sole input sensor. Per IEC 61511 best practice, SIL-rated loops should use redundant sensors with voting logic (1oo2, 2oo3). Where single-sensor configurations exist, prioritize adding diversity. This does not fix the CVE but prevents the worst-case safety outcome if the sensor is manipulated. Schedule during the next SIS proof-test cycle.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone 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 availabilityNo 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.
EPSS0.0052 (0.52%), 58th percentile. Very low predicted exploitation probability — consistent with the physical-proximity barrier and OT niche.
KEV statusNot listed on CISA Known Exploited Vulnerabilities catalog as of 2026-10-03.
CVSS vector discrepancyNVD: 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 versionsVEGAPULS 6X Two-wire PROFINET / Modbus TCP / OPC UA (Ethernet-APL) — firmware ≥1.0.0, <1.1.1. Model designator: PS6X.????????????Y????????.
Fixed versionFirmware 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 exposureEffectively 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 timelineCERT@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 partyInternal discovery by CERT@VDE / VEGA Grieshaber. No external researcher credited. Discovery method noted as internal security review.

Sources.

  1. CERT@VDE Advisory VDE-2026-016
  2. NVD — CVE-2026-3323
  3. CIRCL Vulnerability Lookup — CVE-2026-3323
  4. Offseq Threat Radar — CVE-2026-3323
  5. GitHub Advisory GHSA-rjqm-m642-mm46
  6. VEGA IT Security Guidelines — VEGAPULS 6X (Document 1007792)
  7. VEGA VEGAPULS 6X Operating Instructions — Ethernet-APL variant
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.0/10)

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.

06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously