---
schema: 1
kind: vulnerability
title: "CVE-2025-15467 — Siemens Desigo CC: a vendored OpenSSL CMS parsing overflow gives pre-auth code execution, and the V7 family still has no fix (CVSS 9.8)"
headline: "CISA republishes Siemens' Desigo CC advisory for an OpenSSL CMS overflow — V7 buildings stay unpatched on network segmentation alone"
summary: >
  CISA republished Siemens ProductCERT advisory SSA-734552 on 2026-07-28, covering CVE-2025-15467 in
  Siemens Desigo CC, the building-management platform: a vendored OpenSSL flaw copies an attacker-chosen
  IV length from a CMS AuthEnvelopedData structure into a fixed-size stack buffer, overflowing it before
  any authentication or AEAD tag check runs, and a public command-execution proof-of-concept for the
  underlying OpenSSL flaw is already published.
  Desigo CC V9 is fixed in 9.0.1 and V8 in patch V8.0 QU2.0021, but Siemens records the entire V7 family
  as affected with no fix available, leaving network segmentation as the only control. A second advisory
  the same day covers Mendix Runtime (CVE-2026-7891, CVSS 9.1), where the anonymous role can reach every
  stored user record and no code patch exists.
discovered_at: "2026-07-29T05:10:00Z"
event_date: "2026-07-14"
run_id: 2026-07-29T0408Z-intel
priority: high
immediate_action: null
tags: [vulnerabilities, rce, pre-auth, ot-ics, poc-public, no-patch, patch-available, info-disclosure]
regions: [europe, global]
sectors: [public-sector, energy, water, manufacturing]
entities: []
techniques: [T1190]
affected_products: ["Siemens Desigo CC", "Siemens Mendix Runtime"]
cves:
  - id: CVE-2025-15467
    cvss: "9.8"
    epss: null
    type: memory-corruption
    vector: zero-click
    auth: pre-auth
    status: [poc-public, patch-available, no-patch]
    affected: "Read from the product_status.known_affected block of Siemens' own CSAF: Desigo CC family V7 — all versions; family V8 — all versions; family V9 — versions below 9.0.1. The underlying OpenSSL advisory states OpenSSL 3.6, 3.5, 3.4, 3.3 and 3.0 are vulnerable while 1.1.1 and 1.0.2 are not, and that the FIPS modules in the affected branches are outside the flaw's scope because the CMS implementation sits outside the FIPS module boundary."
    fixed: "Per the remediations block of Siemens' CSAF, the three Desigo CC families diverge: V9 is fixed in 9.0.1 (Siemens styles it \"V9.0 QU1 or later\"); V8 is fixed by applying patch V8.0 QU2.0021; V7 carries remediation category none_available — \"Currently no fix is available\" — with Siemens' network-segmentation guidance as the only offered control. Upstream OpenSSL fixed the flaw in 3.6.1, 3.5.5, 3.4.4, 3.3.6 and 3.0.19, but Desigo CC vendors the library, so the upstream release is not the remediation path for these products."
  - id: CVE-2026-7891
    cvss: "9.1"
    epss: null
    type: auth-bypass
    vector: zero-click
    auth: pre-auth
    status: [mitigation-only]
    affected: "Mendix Runtime, all versions, per the known_affected block of Siemens' CSAF SSA-814963."
    fixed: "No code fix. Siemens' CSAF carries a remediation of category mitigation, directing that any security model relying solely on XPath constraints on a System.User specialization be revised to enforce restrictions at the App Security role-management configuration level instead; the accompanying vendor_fix entry is itself a documentation revision rather than a shipped code change."
sources:
  - url: "https://cert-portal.siemens.com/productcert/csaf/ssa-734552.json"
    publisher: "Siemens ProductCERT (SSA-734552, CSAF)"
    date: "2026-07-14"
    role: primary
  - url: "https://www.cisa.gov/news-events/ics-advisories/icsa-26-209-01"
    publisher: "CISA (ICSA-26-209-01)"
    date: "2026-07-28"
    role: primary
  - url: "https://www.openwall.com/lists/oss-security/2026/01/27/7"
    publisher: "OpenSSL Security Advisory (Tomas Mraz, oss-security)"
    date: "2026-01-27"
    role: corroborating
  - url: "https://github.com/guiimoraes/CVE-2025-15467"
    publisher: "guiimoraes (public proof-of-concept repository)"
    date: "2026-07-28"
    role: corroborating
  - url: "https://cert-portal.siemens.com/productcert/csaf/ssa-814963.json"
    publisher: "Siemens ProductCERT (SSA-814963, CSAF)"
    date: "2026-07-14"
    role: corroborating
  - url: "https://www.cisa.gov/news-events/ics-advisories/icsa-26-209-02"
    publisher: "CISA (ICSA-26-209-02)"
    date: "2026-07-28"
    role: corroborating
closed_sources: []
evidence:
  - quote: "Stack buffer overflow in CMS AuthEnvelopedData parsing (CVE-2025-15467)"
    publisher: "OpenSSL Security Advisory (Tomas Mraz, oss-security)"
  - quote: "Severity: High"
    publisher: "OpenSSL Security Advisory (Tomas Mraz, oss-security)"
  - quote: "Currently no fix is available"
    publisher: "Siemens ProductCERT (SSA-734552, CSAF)"
  - quote: "Update to patch V8.0 QU2.0021"
    publisher: "Siemens ProductCERT (SSA-734552, CSAF)"
  - quote: "Any security model relying solely on XPath constraints on a System.User specialization to restrict access should be revised to enforce restrictions at the App Security role-management configuration level instead."
    publisher: "Siemens ProductCERT (SSA-814963, CSAF)"
verification: multi-source
sourcing_note: >
  The in-window trigger is CISA's republication on 2026-07-28; Siemens ProductCERT itself published both
  advisories on 2026-07-14, which `event_date` records so the age is not obscured. CISA's document is a
  verbatim CSAF republication and says so explicitly, disclaiming responsibility for editorial or
  technical accuracy, so Siemens' own CSAF is cited as the primary and was fetched independently from
  cert-portal.siemens.com rather than read through CISA. Both were read as structured CSAF — the affected
  and fixed values above come from product_status and remediations fields, not from prose. Two severity
  divergences are worth recording: OpenSSL rates the underlying flaw "High" in its own advisory while the
  9.8/CRITICAL score comes from Siemens ProductCERT as the assigning party, and the vulnerable function
  name (evp_cipher_get_asn1_aead_params in crypto/evp/evp_lib.c) appears in third-party analysis of the
  public proof-of-concept rather than in OpenSSL's advisory text, which describes the flaw only as
  affecting CMS AuthEnvelopedData parsing. The public proof-of-concept is cited to the repository that
  publishes it rather than to CISA's advisory, which carries no statement about exploit availability. Two lower-severity items in the same CISA batch — a MikroTik
  RouterOS API rate-limiting flaw that CISA states is not remotely exploitable, and an ABB KNX Update
  Tool firmware-integrity gap requiring physical bus access — are omitted as not clearing this pipeline's
  actionability bar.
confidence: high
update_of: null
references: []
deep_dive: false
deep_dive_category: null
org_triage: null
classification:
  reliability: A
  credibility: 1
watchlist_hit: false
actions:
  - "Inventory Desigo CC installations by family: V9 below 9.0.1 upgrades to 9.0.1, V8 takes patch V8.0 QU2.0021, and every V7 installation has no fix to apply — those need Siemens' network-segmentation controls enforced now, since a public command-execution exploit for the underlying OpenSSL flaw already exists."
  - "On every deployed Mendix application, check whether the anonymous role can read System.User records, and move the restriction from XPath constraints on a System.User specialization to App Security role-management configuration — Siemens states the platform's built-in access rules override the XPath constraints developers commonly rely on here."
migrated_from: null
---

The Desigo CC flaw is a vendored-dependency problem with an unusually clean exploitation precondition. When OpenSSL parses a CMS `AuthEnvelopedData` structure that names an AEAD cipher, the initialisation vector encoded in the ASN.1 parameters is copied into a fixed-size stack buffer without checking that the encoded length fits the destination, so an oversized IV produces a stack out-of-bounds write ([Siemens ProductCERT, 2026-07-14](https://cert-portal.siemens.com/productcert/csaf/ssa-734552.json)); OpenSSL's own advisory confirms the flaw sits in CMS AuthEnvelopedData parsing and rates it High, and states that OpenSSL 3.6, 3.5, 3.4, 3.3 and 3.0 are vulnerable while 1.1.1 and 1.0.2 are not ([OpenSSL, 2026-01-27](https://www.openwall.com/lists/oss-security/2026/01/27/7)). The load-bearing detail for defenders is *when* the overflow fires: it happens during length parsing, before the AEAD tag is verified, so an attacker needs no valid key material and no credential — only a path by which the process is handed a crafted CMS or S/MIME message. Siemens is affected because Desigo CC, its building-management platform, vendors the library for that parsing path, and a public command-execution proof-of-concept for the underlying OpenSSL flaw is already published — though it achieves a shell against a build compiled with stack protection and fortification disabled and ASLR off, and OpenSSL's own advisory notes that exploitability to remote code execution depends on platform and toolchain mitigations ([guiimoraes, 2026-07-28](https://github.com/guiimoraes/CVE-2025-15467); [OpenSSL, 2026-01-27](https://www.openwall.com/lists/oss-security/2026/01/27/7)).

The remediation picture is where this stops being routine. Siemens' structured advisory splits the product line three ways: family V9 is fixed at 9.0.1, family V8 is fixed by patch V8.0 QU2.0021, and family V7 — all versions — carries the remediation category `none_available` with the plain text "Currently no fix is available" ([Siemens ProductCERT, 2026-07-14](https://cert-portal.siemens.com/productcert/csaf/ssa-734552.json)). A pre-authentication memory-corruption bug with public exploit code and no vendor patch, in software that runs heating, ventilation, access control and life-safety integration for real buildings, is not something a quarterly maintenance window addresses. For any V7 estate the only available control is the network position: Siemens points to its own segmentation guidance, which in practice means the Desigo CC server should be unreachable from any network that can hand it untrusted certificate or message content.

The same-day Mendix advisory is a different failure mode with a similar bottom line. Siemens describes it not as a code bug but as an access-control-model gap — Mendix's documentation does not adequately convey the reserved behaviour of the built-in `System.User` entity, and the common consequence is that the anonymous user role reaches every stored user record even though no access rights were explicitly configured for it ([CISA, 2026-07-28](https://www.cisa.gov/news-events/ics-advisories/icsa-26-209-02)). The mechanism matters because it defeats the obvious defence: Siemens states that `System.User` carries platform-enforced access rules that cannot be overridden or restricted by access rules defined on a specialization, so a developer who wrote XPath constraints on a `System.User` specialization and believed the data was fenced off is wrong, and the remediation is to enforce the restriction at the App Security role-management level instead ([Siemens ProductCERT, 2026-07-14](https://cert-portal.siemens.com/productcert/csaf/ssa-814963.json)). All Mendix Runtime versions are affected and there is no code patch to wait for.

Detection: for Desigo CC the honest observable is thin, because a pre-auth memory-corruption attempt against a vendored parser leaves little application-level trace — the telemetry class to watch is process-crash and crash-dump events on hosts running Desigo CC server components, correlated in time with inbound content that would reach a CMS, PKCS#7 or S/MIME parsing path, since a failed overflow attempt is far more likely to crash the process than a successful one is to log anything. For Mendix the observable is much more direct and lives in application access logs: unauthenticated requests to the app's REST or OData endpoints that return user records the requester has no relationship to. **Triage:** on the Mendix side, an anonymous endpoint returning a single record tied to the requester's own session can be normal application behaviour, while an anonymous request enumerating user records beyond the requester's own is the signal — the discriminator is the breadth of the result set, not the fact of an unauthenticated call.