ServiceNow Fixes Put Admin Scripts And Plaintext Passwords In Incident Scope

ServiceNow has disclosed two AI Platform vulnerabilities in its October advisory. CVE-2026-103093 is a critical Rhino sandbox escape that can let an authenticated user with the admin role execute arbitrary code on the host operating system. CVE-2026-103094 is a high-severity information disclosure flaw that can persist a user's plaintext password in a system table where another user may be able to view it.

ServiceNow says hosted instances received an update and that partners and self-hosted customers were given the fix. It reports no known malicious exploitation. The public records do not identify affected release ranges, patched build numbers, the vulnerable script surface, the table involved, or reliable indicators. Customers should verify instance-specific update status through the official advisory and support channel, review high-risk admin activity and custom scripts, protect and export logs, and rotate credentials only after establishing which passwords may have persisted and who could read them.

ServiceNow's October 2026 advisory links two new CVE records. CVE-2026-103093 carries a 9.4 CVSS 4.0 score. ServiceNow says an authenticated user with the admin role could bypass Rhino sandbox restrictions and execute arbitrary code on the operating system beneath the AI Platform. The record gives the flaw a network attack vector, high privileges, no user interaction, and high impact across the vulnerable and subsequent systems.

CVE-2026-103094 carries a 7.1 score. It can cause a user's plaintext password to be persisted in a system table and potentially exposed to another user who would not otherwise be entitled to view it. Its CVSS vector describes low privileges and additional attack requirements, but the public description does not identify the workflow that stores the password, the table, the access rule, how long the value remains, or which user roles can retrieve it.

ServiceNow says it updated hosted instances and supplied the update to partners and self-hosted customers. For both CVEs, the company says it is not currently aware of malicious exploitation. The public GitHub records list affected and patched versions as unknown. That makes the official support advisory and each customer's instance status the authoritative patch evidence; a guessed family name or generic latest-version claim is not enough.

The Rhino issue is a privilege-boundary failure. ServiceNow permits server-side scripting inside a constrained runtime. The disclosed flaw lets an existing administrator cross from that sandbox to the host operating system. The prerequisite matters because an unauthenticated internet user cannot invoke the public record's chain directly. The consequence matters because a compromised admin account, malicious administrator, or attacker who already gained the role may move from platform configuration into host-level execution.

The password issue is a data-lifecycle failure. A credential that should be transient and protected instead remains as plaintext in a database table. Exploitation does not necessarily require operating-system code execution. It depends on a password first being stored by the vulnerable workflow and a second principal having a way to view the record. The resulting risk can extend beyond ServiceNow if the affected password was reused or authenticates to an upstream identity account.

Nothing in the public record says the two vulnerabilities were chained, share a root cause, or affected the same instances. Investigators should maintain separate timelines: one for admin access, scripts, processes, and host effects; another for the password-handling workflow, records created, table access, exports, and later authentication. Combining them too early can produce both overreaction and missed evidence.

Hosted customers should confirm that every production and sub-production instance received the relevant security update and review any Customer Actions tied to the advisory. ServiceNow's October security guide says some security work arrives automatically through family releases or patches, while other Customer Actions require manual implementation. Record the update or maintenance evidence, instance name, environment, completion time, and any exceptions.

Partners and self-hosted customers need to apply the supplied update or move to a patched release using ServiceNow's instructions. The public CVE pages do not provide safe build thresholds, so do not turn an unverified version comparison into a compliance statement. Open a support case if the advisory does not show the exact applicable patch for an instance, and preserve the answer with the change record.

Test the fix first in a representative non-production instance when ServiceNow's emergency direction allows it, then validate critical workflows, integrations, custom applications, MID Servers, scheduled jobs, and authentication after production deployment. For self-hosted systems, confirm the running nodes and services actually changed. A downloaded package, completed change ticket, or hosted-service assumption is weaker evidence than an instance-specific update record and runtime verification.

Build a list of every account, group, and integration identity holding the admin role during the affected window. Include native accounts that bypass the main identity provider, emergency accounts, impersonation paths, support access, delegated development identities, and dormant administrators. Review role additions, removals, escalations, unusual login sources, new sessions, and activity outside normal maintenance windows.

Preserve changes to server-side scripts, business rules, script includes, scheduled jobs, flows, actions, applications, plugins, and other executable customization. The public advisory does not identify the exact vulnerable Rhino surface, so broad evidence collection is warranted when suspicious admin activity exists. It is not evidence that every custom script is vulnerable. Compare current records with source control, application packages, update sets, or trusted baselines and investigate unexplained differences.

For self-hosted environments, extend the hunt to the operating system: service-account activity, child processes, shell or interpreter launches, new files, persistence, outbound connections, database access, and credentials reachable from the platform host. Hosted customers do not control that layer and should use ServiceNow's advisory, support findings, instance telemetry, and any customer-specific notification rather than pretending instance logs provide full infrastructure visibility.

Ask ServiceNow to identify the affected workflow, table, field, release boundary, and method for finding records created before remediation. Avoid broad searches that copy sensitive values into query history, exports, screenshots, tickets, or SIEM fields. Restrict the investigation to a small authorized group and preserve record metadata, access history, and affected-user identifiers without reproducing plaintext passwords unnecessarily.

Determine who could read the table and who actually did. Review ACL and role changes, list and form views, queries, exports, reports, APIs, integrations, backups, clones, and support access that touched the relevant records. ServiceNow's logging guide says transaction logs capture browser interactions and audit records can retain record changes, but logging coverage depends on configuration. An absence of a retained event should be reported as an evidence limit, not proof that no access occurred.

If a password was persisted and unauthorized access is plausible, change it at the identity system that accepts it, terminate relevant sessions where supported, and review authentication after the first possible exposure. Address reuse across email, identity providers, VPN, developer tools, and other services through direct user outreach. Do not claim that every ServiceNow password needs rotation until the affected workflow and records are known, but do not leave a confirmed plaintext credential valid while waiting for perfect attribution.

ServiceNow's current security guide recommends forwarding logs to an organizational SIEM, protecting critical log tables against tampering, reviewing login and privilege-escalation events, monitoring system and transaction logs, and enabling auditing on tables that need perpetual history. Verify those controls now. The guide says transaction logs retain eight weekly rotations while table auditing is selective, so response speed and existing configuration determine how much history remains.

Create a case with ServiceNow for any unexplained administrator activity, suspicious scripting, possible table access, or uncertainty about patch state. Ask for the instance-specific maintenance record, supported indicators, relevant time window, affected surfaces, and whether provider-side infrastructure review found anything. Keep hosted platform findings, customer instance findings, self-hosted operating-system evidence, and downstream identity activity in separate evidence tracks.

Several material facts remain unpublished: affected and fixed release ranges, vulnerable endpoints or script types, the password table and workflow, default visibility of the record, retention behavior, exploitation indicators, and discovery timelines. Those gaps limit strong negative conclusions. The justified response is not to assume a breach. It is to prove the update, narrow privileged access, protect logs, investigate the two disclosed paths according to their prerequisites, and document where the public record or local telemetry cannot answer the question.