Suspicious Update Set XML

This page describes the nowisor-update-set-xml-suspicious check from the nowisor Instance Scan Pack v1.0.0. The check is a ColumnTypeCheck over the payload column of sys_update_xml (XML column type). It scans each update set payload for three high-impact patterns: admin role grants (<sys_user_has_role> elements with role name admin), ACL modifications (<sys_security_acl> elements), and cross-scope privilege grants (<sys_scope_privilege> elements). Each match produces one finding identifying the parent update set, the matched element type, and the record context.

What this finding means

Every finding identifies one sys_update_xml row whose serialized payload contains one or more of the three high-impact patterns. The patterns are not vulnerabilities on their own — legitimate platform administration involves all three from time to time. They are flagged because each is a documented attack-path artifact: ways an attacker uses the update-set promotion pipeline to plant persistence or weaken controls.

The three patterns:

1. <sys_user_has_role> containing role name admin — an update set that includes an admin role grant. Legitimate cases: provisioning a new platform administrator, restoring a role grant lost during an upgrade. Attack cases: planting a backdoor by adding admin to an attacker-controlled account in an otherwise-innocent update set.

2. <sys_security_acl> element — an update set that includes an ACL record (creating, modifying, or deleting one). Legitimate cases: shipping security-baseline hardening changes through normal change management. Attack cases: weakening an ACL to enable post-deployment data access, with the change appearing as part of a larger functional update.

3. <sys_scope_privilege> element — an update set that includes a cross-scope privilege grant. Legitimate cases: a scoped application installation that documents its required global-scope interactions. Attack cases: granting cross-scope privileges to an attacker-controlled scoped app that subsequently uses those privileges to mutate global data.

Update sets are the primary deployment vehicle for ServiceNow configuration. Every change that flows from dev to test to production passes through the sys_update_xml records that compose an update set. The check is positioned at this gate because update-set review is where defenders have the best opportunity to catch malicious or accidental promotion of high-impact artifacts.

Why it matters for your compliance

Update set security maps directly to change-management controls.

NIS2 Article 21§2(f) — policies and procedures to assess effectiveness of cybersecurity measures. NIS2's effectiveness-assessment language explicitly covers change-management practices. Update set artifacts are the technical objects that change management governs; an entity that cannot demonstrate review of high-impact update set contents is failing the implementation of its own policy.

ISO 27001 A.8.32 — change management. A.8.32 is the change-management control directly. The control text requires that changes be reviewed before promotion. Update sets are how changes are promoted in ServiceNow; the check provides the technical means to identify which update sets warrant deeper review.

Severity 1 (critical) because the failure mode is supply-chain-grade: a malicious update set that promotes to production becomes persistent platform compromise. The check is the most-direct technical control against this attack class.

The attack path

The path runs through update-set authoring and promotion. The attacker doesn't need to compromise production directly — they need to land malicious content in an update set that production accepts.

Step 1 — Author the malicious content in a development scope. The attacker has access to a development instance — either directly (as an internal developer with malicious intent or compromised credentials) or indirectly (through a third-party developer whose access was compromised). They author the malicious record:

• An admin role grant on sys_user_has_role for an attacker-controlled user.
• A weakened ACL that opens access on sys_user.user_password or another sensitive surface.
• A cross-scope privilege grant from a scoped app the attacker controls to global, enabling later mutation.

Step 2 — Embed in a legitimate update set. The attacker bundles the malicious record with a larger functional change — a new field, a new business rule, a workflow modification. The functional change is the cover story; reviewers focus on it during code review. The malicious record is a side payload that may not be inspected as carefully.

Step 3 — Promote through normal channels. The update set passes through the dev → test → production pipeline. At each stage, reviewers may apply different levels of scrutiny: dev → test review may be functional-only; test → production review may be more rigorous but typically focuses on regression risk, not on whether the update set contains privilege escalations.

Step 4 — Activate. The update set commits to production. The platform applies the malicious record alongside the legitimate changes. The attacker's role grant now exists in sys_user_has_role; the weakened ACL is in sys_security_acl; the cross-scope grant is in sys_scope_privilege. The attacker exploits the resulting state at their leisure.

Step 5 — Persistence. Because the record entered through the official promotion pipeline, it appears in sys_update_xml as a normal change. Audit reviews of "what did update set X contain" require examining the XML payload, not just the parent record list. Many entities don't review XML payloads systematically; the malicious record persists undetected.

The check operationalizes the XML-payload review. By scanning sys_update_xml.payload for the three high-impact patterns, it surfaces the specific update sets that contain artifacts warranting deeper review.

How to fix it

The remediation is per-finding review, not a configuration change.

Step 1 — Open each flagged update set. The finding identifies the sys_update_xml record's parent update set. Navigate to System Update Sets → Retrieved Update Sets (or the local update sets list for in-instance work) and open the parent.

Step 2 — Review the matched record type. For each finding, determine which pattern triggered it (admin role grant, ACL modification, cross-scope grant) and locate the specific record in the update set:

• For role grants: review which user received the role, who authored the grant, and whether the assignment matches the documented business case.
• For ACL modifications: open the ACL record, review the operation, target, role, and condition script. Compare against the OOB baseline (if applicable) or against the documented hardening intent.
• For cross-scope grants: review the source scope, target scope, and operation. Confirm the grant is necessary for the application's documented function.

Step 3 — Approve or reject. Update sets that contain legitimate, documented changes can be approved. Update sets that contain artifacts without clear business justification should be rejected — either reverted (if already committed) or returned to the originator for explanation.

Step 4 — Strengthen the upstream review. The check surfaces what should have been caught earlier in the pipeline. For each finding, ask: why did this update set reach the production gate without the relevant artifact being noticed? The answer often points to a review process gap. Improvements: structured update-set review checklists, separation of duties between authoring and promotion, sign-off requirements for update sets containing role grants or ACL changes.

Step 5 — Purge historical credential data. If your sys_update_xml records contain old payloads with credential values (passwords, API keys that were captured in update sets before the credential was rotated), those payloads remain extractable by anyone with read access to the table. Audit and purge or redact as appropriate.

How to verify the fix

/*
 * Verify nowisor-update-set-xml-suspicious
 * Read-only, safe for production.
 * Counts sys_update_xml records matching the three patterns.
 */
(function auditUpdateXml() {
    var patterns = [
        { name: 'admin role grant', re: /<sys_user_has_role>[\s\S]*?admin[\s\S]*?<\/sys_user_has_role>/i },
        { name: 'ACL modification', re: /<sys_security_acl>/i },
        { name: 'cross-scope grant', re: /<sys_scope_privilege>/i }
    ];
    var counts = { 'admin role grant': 0, 'ACL modification': 0, 'cross-scope grant': 0 };

    var gr = new GlideRecord('sys_update_xml');
    gr.setLimit(1000);  // sample for verification; full check covers all records
    gr.query();
    while (gr.next()) {
        var payload = gr.getValue('payload') || '';
        for (var i = 0; i < patterns.length; i++) {
            if (patterns[i].re.test(payload)) counts[patterns[i].name]++;
        }
    }
    gs.print('Sample of 1,000 sys_update_xml records:');
    for (var k in counts) gs.print('  ' + k + ': ' + counts[k]);
})();

The full nowisor scan covers every record; the script above samples for a quick check. Track findings over time; a clean state on a stable instance means update set review processes are catching high-impact artifacts before promotion.

What to do next

Update-set artifacts often pair with the code-discipline cluster:

• nowisor-eval-usage-detector — eval() calls in update set scripts are flagged by the same code-discipline check that catches them in live code. An update set containing eval() plus a role grant is the canonical AP-007 chain delivered via promotion.
• nowisor-set-roles-detector — setRoles() in update set scripts is a session-mutation primitive shipped via promotion.
• nowisor-set-workflow-false-detector — audit-bypass scripts shipped via update set inherit the bypass behavior in production.
• nowisor-cross-scope-privilege-grants — the standing scope grants this check finds. Update-set review is where new grants enter; the standing grant check is where existing grants are audited.

For organizations operating under change-management compliance scrutiny, the nowisor advisor product is being built to cross-reference update-set findings with the change-request tracking system — surfacing the specific CRs that authorized each high-impact promotion and flagging the promotions that have no linked CR. Audit your update set promotion pipeline →