ServiceNow disclosed three critical vulnerabilities in its AI Platform on January 14, 2025. All three received CVSS scores at maximum severity. The flaws, CVE-2026-18885 (code injection), CVE-2026-18886 (privilege escalation), and CVE-2026-74820 (SQL injection), can be exploited by unauthenticated attackers using low-complexity methods. No active exploitation has been reported. ServiceNow released patches and advised immediate updates.
The platform powers more than 100,000 enterprise AI applications at 85% of Fortune 500 companies, making this disclosure significant for enterprise security teams.
Timeline
January 14, 2025: ServiceNow publicly disclosed the three vulnerabilities and released patches.
Post-disclosure: ServiceNow advised customers to update their systems immediately. The company confirmed no active exploitation had been observed at the time of disclosure.
The quick timeline between discovery and public disclosure suggests ServiceNow identified these issues through internal security review rather than observing active exploitation.
Which Controls Failed or Were Missing
This incident isn't a breach but a disclosure of vulnerabilities found before exploitation. The flaws reveal control gaps in the development process:
Secure coding practices: Code injection and SQL injection vulnerabilities indicate insufficient input validation and parameterization during development. These are preventable through static analysis and secure coding training.
Pre-production security testing: The presence of three maximum-severity vulnerabilities suggests gaps in security testing coverage. Dynamic application security testing (DAST) and penetration testing should catch SQL injection and code injection flaws before release.
Authentication boundaries: The fact that unauthenticated users can trigger these vulnerabilities means authentication controls weren't enforced at critical execution points. API endpoints and data access layers should require authentication by default.
Privilege separation: The privilege escalation flaw (CVE-2026-18886) indicates insufficient role-based access controls or improper validation of user privileges during sensitive operations.
What the Standards Require
OWASP ASVS v4.0.3 directly addresses these vulnerability classes:
- Requirement 5.3.4: "Verify that data selection or database queries use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks."
- Requirement 5.2.1: "Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature."
- Requirement 4.1.1: "Verify that the application enforces access control rules on a trusted service layer."
PCI DSS v4.0.1 Requirement 6.2.4 mandates that "bespoke and custom software are developed securely" with specific sub-requirements:
- 6.2.4.1: Software development personnel receive training on secure development techniques at least annually.
- 6.2.4.2: Software is reviewed prior to release to identify and correct potential security vulnerabilities.
NIST 800-53 Rev 5 Control SI-10 (Information Input Validation) requires that applications "check the validity of information inputs" and defines this as a foundational security control. The SQL and code injection vulnerabilities represent direct failures of input validation.
ISO 27001 Annex A.8.25 (Secure development lifecycle) requires organizations to establish and apply rules for the development of software. The presence of three maximum-severity vulnerabilities in production code indicates process gaps in applying these rules.
Lessons and Action Items for Your Team
Build parameterized queries into your coding standards. Don't rely on developers remembering to sanitize inputs. Your ORM configuration or database access layer should make SQL injection difficult by default. Review your current codebase: can developers execute raw SQL without parameterization? If yes, that's your first fix.
Require authentication for all API endpoints by default. The "unauthenticated attacker" detail in this disclosure is the most concerning element. Your framework should enforce authentication unless explicitly overridden with documented justification. Audit your current APIs: which endpoints accept unauthenticated requests? Document why each one needs to be public.
Run SAST and DAST in your CI/CD pipeline, not as a quarterly exercise. Tools like Semgrep or SonarQube can catch SQL injection patterns before code review. Configure them to fail builds on high-severity findings. Don't gate on every warning initially, start with injection flaws and authentication bypasses, then expand coverage.
Test privilege escalation paths explicitly. Create test cases where low-privilege users attempt administrative actions. Your test suite should include attempts to access other users' data, modify system settings, or execute privileged functions. If you're using role-based access control, test every role boundary.
Establish a patch deployment SLA for critical vulnerabilities. ServiceNow released patches immediately upon disclosure. Your team needs a documented process for evaluating and deploying vendor patches within a defined timeframe. PCI DSS v4.0.1 Requirement 6.3.3 requires patching critical vulnerabilities within one month of release. For platforms touching payment data or sensitive customer information, consider a shorter window.
Map your vendor platforms to business impact. ServiceNow powers AI applications at 85% of Fortune 500 companies. Do you know which vendors have similar reach in your environment? Create a list of your top 10 platforms by business criticality. These get priority for patch deployment and security monitoring.
Document your authentication boundaries. Review which services, APIs, and functions require authentication versus allowing anonymous access. This should be a documented architecture decision, not something discovered during incident response. If you can't quickly answer "what can an unauthenticated user do in our environment?", that's a gap.
The ServiceNow disclosure demonstrates effective vulnerability management by the vendor, finding and patching issues before exploitation. Your job is ensuring you can deploy those patches before someone else finds the same vulnerabilities in your environment.
