On 27 August 2026, ServiceNow published a security advisory covering four vulnerabilities in its platform. Three of them reach the maximum score of 10.0 on the CVSS scale. For security teams, this is a top-priority alert. For GRC teams, the situation is more uncomfortable still: the tool they use to document their compliance and manage their risks is among the targets.
Four flaws, three perfect scores
ServiceNow identified and fixed four CVEs affecting its AI Platform. The first three each carry a CVSS 10.0 score, the maximum on the scale. The score reflects a combination of unauthenticated exploitability, total impact on confidentiality, integrity and availability, and a network attack surface reachable remotely.
CVE-2026-18885: code injection in the Composite Data GraphQL API. An unauthenticated attacker can run arbitrary code and access all of the instance's data.
CVE-2026-18886: broken access control in the configuration upload processor. An unauthenticated attacker can create or modify data, which allows them to escalate their privileges on the instance.
CVE-2026-74820: SQL injection via the ORDER BY clause of the dynamic schema. An unauthenticated attacker can run arbitrary SQL queries against the underlying database.
The fourth vulnerability, CVE-2026-6876, has a CVSS 4.0 score of 8.7. It concerns the script sandbox of the Now Platform and allows an escape leading to code execution.
As of 28 August 2026, ServiceNow had observed no active exploitation of these flaws. That window is short: past experience shows that critical vulnerabilities without authentication are exploited in production within days of their publication.
Why GRC teams are directly concerned
ServiceNow is deployed in more than 85% of Fortune 500 companies (source: ServiceNow, 2026 annual report). Beyond IT service management, the platform hosts risk management, internal audit, regulatory compliance and third-party management modules: precisely the scopes that NIS2 and DORA require you to document and keep up to date.
The practical consequence is direct. An attacker exploiting CVE-2026-18885 gains access not only to connected IT systems, but potentially to the entire risk register, audit evidence, compliance reports and supplier access stored in the instance. For an entity subject to NIS2, compromising this tool can trigger an incident notification obligation and a loss of integrity in compliance evidence at the same time.
This is the paradox of governance platforms: centralised to gain efficiency, they become high-value assets for an attacker. Access to a GRC instance provides a map of an organisation's security architecture, its documented weaknesses and its audit calendar.
What NIS2 expects of you now
Article 21 of NIS2 requires essential and important entities to put in place technical and organisational risk management measures. Patch management is explicitly part of them. A patch available for a CVSS 10.0 vulnerability on a production system must be applied without delay, and that delay must be documented.
If your ServiceNow instance is hosted (cloud), the vendor has deployed the fixes automatically. Your action is limited to verifying that the update has been applied and keeping evidence of it in your risk register.
If your instance is self-hosted, you must apply the fixes manually for your version. The affected versions cover the Xanadu branch (before Patch 11 Hot Fix 7a), the Yokohama branch (before Patch 12 Hot Fix 3b and Patch 13 Hot Fix 4) and the Zurich branch. ServiceNow made the updates available on the day of disclosure.
In both cases, detection deserves attention. Do you have enough access logs to rule out exploitation before the 27 August publication? If the instance was exposed to the Internet without strict network access control, reviewing the logs of the last 30 days is prudent.
Three priority actions
First action: determine immediately whether your instance is hosted or self-hosted, and confirm that the fix has been applied. For a self-hosted instance, apply the patch within 24 to 48 hours if this has not yet been done.
Second action: assess whether exploitation could have occurred before 27 August. If your risk analysis concludes that the probability is not zero, and personal data or sensitive information is held in the instance, the GDPR notification obligations (72 hours to the French data protection authority (CNIL)) and NIS2 obligations (24 hours to the French national cybersecurity agency (ANSSI)) apply. The article GDPR and NIS2: one incident, two notifications details how these two regimes are coordinated.
Third action: record the fix in your risk register. Proof of correction is audit evidence. A fix that is applied but not documented does not count during a NIS2 inspection.
The broader signal
This disclosure illustrates a structural trend. Enterprise SaaS platforms (GRC, ITSM, ERP) concentrate critical data and are becoming increasingly attractive targets. The attacker's logic is simple: compromising one central platform is worth more than compromising ten peripheral systems.
The answer is not to avoid centralised platforms: their efficiency gains remain real. It is to treat them with the same level of vigilance as any other critical system. That means active update management, network segmentation that limits exposure, and regular reviews of access, in particular service accounts and third-party integrations, which are the vectors most often overlooked in this kind of environment.
Access management for GRC platforms is precisely one of the points that NIS2 auditors check first. The article IAM and NIS2/DORA: the access control your audit will flag first details the applicable requirements.