OpenSSL CMS AuthEnvelopedData parsing stack buffer overflow (CVSS 9.8 per Siemens ProductCERT; OpenSSL rates it High) — pre-auth, fires before AEAD tag verification; vendored in Siemens Desigo CC, where family V7 has no fix available, V8 is fixed by patch V8.0 QU2.0021 and V9 by 9.0.1; public command-execution PoC

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)

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); 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). 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; OpenSSL, 2026-01-27).

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). 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). 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). 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.