What Happened
On June 5, 2026, ServiceNow applied an emergency security update after discovering that attackers had exploited an unauthenticated REST endpoint to query customer instance data. The vulnerable endpoint, /api/now/related_list_edit/create, was configured with requires_authentication=false, allowing anyone aware of the endpoint to make queries without credentials. The incident primarily affected customers on the Australia platform release and those who had made specific configuration changes that exposed this endpoint.
Timeline
Pre-June 5, 2026: Attackers discovered and began exploiting the unauthenticated endpoint. ServiceNow has not disclosed the duration of exposure.
June 5, 2026: ServiceNow deployed a security update restricting the endpoint to authenticated users only.
Post-update: ServiceNow opened support cases to notify affected customers and began incident response procedures.
The company has not publicly disclosed how the vulnerability was initially discovered, whether through internal security testing, external reporting, or detection of active exploitation.
Which Controls Failed or Were Missing
1. Secure-by-Default API Configuration
The root cause was an API endpoint shipped with authentication disabled, violating the principle of least privilege. Every API endpoint should require explicit authentication unless there's a documented business reason and compensating controls.
2. API Inventory and Security Testing
ServiceNow's internal security testing failed to identify this misconfiguration before deployment. This suggests gaps in:
- API discovery: No comprehensive inventory of all exposed endpoints and their authentication requirements.
- Pre-deployment security scanning: Automated checks for common misconfigurations like
requires_authentication=falsewere either absent or ineffective. - Penetration testing scope: External security assessments may not have covered all REST endpoints, particularly those in platform-specific releases.
3. Runtime API Monitoring
The incident timeline suggests attackers exploited this endpoint for an unknown duration before detection, indicating insufficient monitoring for:
- Unusual API access patterns from unauthenticated sources.
- Queries to sensitive endpoints that should never receive unauthenticated traffic.
- Anomalous data access volumes or query patterns.
4. Configuration Management Controls
The fact that "certain configuration changes" could expose this vulnerability indicates weak change management. Organizations need controls that prevent security-critical settings from being modified without review, particularly authentication requirements on data-access endpoints.
What the Standards Require
PCI DSS v4.0.1
Requirement 6.4.2 mandates that solutions are developed based on industry standards and incorporate information security throughout the software development lifecycle. This includes secure coding practices that would flag authentication bypasses.
Requirement 6.4.3 requires that software engineering techniques or other methods are defined and in use to prevent or mitigate common software attacks and related vulnerabilities.
Requirement 11.6.1 requires a change-detection mechanism to alert personnel to unauthorized modifications of critical system files, configuration files, or content files. API authentication settings qualify as critical configuration.
OWASP API Security Top 10
This incident maps directly to API1:2023 - Broken Object Level Authorization. The endpoint allowed users to access objects (customer data) without proper authorization checks. It also touches API2:2023 - Broken Authentication since the endpoint lacked authentication entirely.
ISO/IEC 27001:2022
Control 8.3 (Access control) requires that access to information and other associated assets be limited in accordance with established access control policies. An unauthenticated endpoint violates this at the most basic level.
Control 8.20 (Networks security) requires that networks and network devices be secured, managed, and controlled to protect information in systems and applications. This includes API gateways and endpoint security.
Lessons and Action Items for Your Team
1. Build an API Authentication Baseline
Create a policy that every API endpoint requires authentication by default. Document exceptions—public health checks, webhook receivers with signature validation—and require security review for each one.
Action: Scan your codebase for authentication configuration patterns. In ServiceNow's case, search for requires_authentication=false. In your frameworks, find the equivalent: @AllowAnonymous, permitAll(), public: true.
2. Implement Pre-Deployment API Security Scanning
Add automated checks to your CI/CD pipeline that fail builds when they detect:
- Endpoints without authentication decorators.
- Missing authorization checks on data access operations.
- API routes that don't enforce rate limiting.
Action: Integrate tools like OWASP ZAP API Scan, 42Crunch API Security Audit, or build custom linters that parse your API framework's routing configuration. Set these as required pipeline stages, not optional quality checks.
3. Maintain a Living API Inventory
You can't protect what you don't know exists. Platform-specific releases, as in ServiceNow's case, create blind spots.
Action: Deploy API discovery tools that monitor runtime traffic to identify all active endpoints. Tools like Traceable AI, Salt Security, or even parsing your API gateway logs can reveal shadow APIs. Cross-reference this runtime inventory against your design documentation monthly.
4. Monitor for Unauthenticated Access to Authenticated Endpoints
Even with proper configuration, you need detection for when things break.
Action: Set up alerts for:
- Any successful request to data-access endpoints without valid authentication tokens.
- Spike in 401/403 responses (potential scanning activity).
- Queries from IP ranges that shouldn't access your APIs.
If you're using an API gateway (Kong, Apigee, AWS API Gateway), these metrics should be built into your security dashboard. If you're not using a gateway, start logging authentication decisions at the application layer.
5. Treat Configuration as Code
Authentication settings shouldn't be toggleable through a UI without audit trails and approval workflows.
Action: Move API security configuration into version-controlled files. Require pull request reviews for changes to authentication requirements. Use tools like Open Policy Agent or cloud-native policy engines to enforce "no unauthenticated data access" as code.
6. Segment Your API Attack Surface
ServiceNow's incident affected specific platform releases. You can limit blast radius through segmentation.
Action: Deploy separate API gateways or authentication domains for different customer tiers, regions, or sensitivity levels. A breach in your Australia platform shouldn't automatically expose your European instances.
The ServiceNow incident wasn't sophisticated—it was a configuration error that any organization could make. The difference between a footnote and a customer notification comes down to whether you catch it in testing or production. Build the scanning, monitoring, and policy enforcement that catches requires_authentication=false before your customers do.
