Which versions of SINEC Security Monitor are affected by CVE-2025-40831?

Siemens SINEC Security Monitor instances running versions below V4.10.0 can have their report-generation capability degraded or halted by a user holding a valid low-privileged account.

How to fix or mitigate CVE-2025-40831?

Within 24 hours, inventory every SINEC Security Monitor instance and confirm which run versions below V4.10.0, tighten reporting-feature access to the smallest set of accounts that genuinely need it, and check logs for malformed date parameters or repeated failed report jobs originating from low-privileged users; because this is an authenticated, availability-only issue with no public exploit identified at time of analysis, an emergency change is not justified. Within 7 days, schedule and begin upgrading affected systems to V4.10.0 - the vendor-released patch referenced in the advisory - through your normal change window, and in the interim enforce approved date formats for report generation and require staff to report any report-generation failures so degradation is detected early rather than discovered at reporting deadlines. Within 30 days, complete the V4.10.0 upgrade across all remaining instances, verify that report generation functions normally post-upgrade, and add SINEC Security Monitor to the routine patch-cadence review so future releases from this product line are triaged alongside other security-tooling dependencies.

SINEC Security Monitor CVE-2025-40831

Q: What is the CVSS score of CVE-2025-40831?

CVE-2025-40831 has a CVSS 4.0 base score of 7.1 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

HIGH

Improper Input Validation (CWE-20)

2025-12-09 productcert@siemens.com

Denial Of Service Siemens Sinec Security Monitor

7.1

CVSS 4.0 · Vendor: siemens

Severity by source

Vendor (siemens) PRIMARY

7.1 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

4.3 MEDIUM

Network-reachable low-complexity flaw needing a low-privileged account (PR:L); no confidentiality/integrity impact and DoS limited to the report feature, so A:L rather than A:H.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (siemens).

CVSS VectorVendor: siemens

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Metadata Corrected

Oct 07, 2026 - 20:40 vuln.today

tag: Siemens added

Analysis Generated

Oct 07, 2026 - 20:33 vuln.today

CVE Published

Dec 09, 2025 - 16:17 cve.org

HIGH 7.1

DescriptionCVE.org

A vulnerability has been identified in SINEC Security Monitor (All versions < V4.10.0). The affected application lacks input validation of date parameter in report generation functionality. This could allow an authenticated, lowly privileged attacker to cause denial of service condition of the report functionality.

AnalysisAI

Improper validation of the date parameter in the report-generation feature of Siemens SINEC Security Monitor (all versions below V4.10.0) allows an authenticated, low-privileged user to submit a malformed date value and degrade or halt report generation, producing a denial-of-service condition confined to that functionality. Exploitation requires a valid account and access to the reporting feature - the CVSS vectors (PR:L) confirm it is not reachable by anonymous or unauthenticated attackers - and no public exploit code has been identified at time of analysis, with EPSS placing likelihood of exploitation at 0.39% (31st percentile). Siemens has released V4.10.0, which resolves the flaw; overall this is a moderate-severity, availability-only issue with limited real-world urgency.

Technical ContextAI

The root cause is CWE-20 (Improper Input Validation): the application accepts a user-supplied date value during report generation and processes it without validating format, range, or type, so a crafted value triggers an unhandled error or resource-consumption condition that disrupts the reporting subsystem. The affected component is identified by CPE cpe:2.3:a:siemens:sinec_security_monitor:*:*:*:*:*:*:*:* - a Siemens security monitoring application - and the flaw is present in every release prior to V4.10.0. Impact is availability-only: the CVSS:3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) shows no confidentiality or integrity loss and no scope change, meaning the failure is contained within the report-generation function rather than the whole product. Because the attack path requires network reachability to the interface plus a usable authenticated session, it is a post-authentication, low-privilege abuse case rather than a pre-auth remote compromise, and no non-default configuration or user interaction is needed beyond having an account that can invoke reporting.

RemediationAI

Upgrade SINEC Security Monitor to V4.10.0 or later - vendor-released patch: V4.10.0 - following the instructions in Siemens ProductCERT advisory SSA-882673 (https://cert-portal.siemens.com/productcert/html/ssa-882673.html). If upgrading cannot be done immediately, compensating controls should target the precondition (an authenticated low-privileged account invoking report generation): restrict report-generation privileges to a small set of trusted administrative roles so ordinary users cannot reach the vulnerable parameter (trade-off: reduces reporting availability for regular staff and requires role-model changes), and limit network exposure of the management/reporting interface to trusted administrative segments (trade-off: complicates remote administration but removes the attack path for non-admin users). Monitoring can supplement these: alert on repeated report-generation failures or anomalous date parameters in audit logs, and treat clustered failures as a possible DoS attempt. The DoS does not corrupt data and is recoverable by restarting or re-triggering the reporting service, so service-impact is temporary; no other workaround is published by the vendor at time of analysis, and no public exploit code has been identified.