What Happened
On June 5, ServiceNow issued security update KB3067321 for hosted customers after discovering an API endpoint that allowed unauthenticated access to customer data. The vulnerable endpoint, /api/now/related_list_edit/create, was configured with requires_authentication = false, leaving it exposed.
The vulnerability was identified through ServiceNow's bug bounty program. While the initial advisory suggested the issue was confined to the Australia release, customer discussions indicate older releases may also be vulnerable. ServiceNow attributes access activity to security researchers, but the full scope of access remains under investigation.
Timeline
Pre-June 5: Unknown period where the endpoint remained unauthenticated. ServiceNow has not disclosed when the configuration error was introduced or how long it persisted.
Bug bounty submission: Security researcher reports the unauthenticated endpoint through ServiceNow's bug bounty program.
June 5: ServiceNow deploys KB3067321 security update to hosted customers and issues advisory.
Post-patch: Customers begin reviewing logs to differentiate between researcher activity and potential malicious access. Questions emerge about whether the vulnerability affects releases beyond Australia.
Which Controls Failed or Were Missing
1. Secure-by-Default Configuration
The endpoint shipped with authentication disabled. Security controls should default to a secure state — requiring explicit action to disable authentication, not to enable it.
2. Pre-Production Security Testing
This configuration should have been caught during security testing before release. An API endpoint that creates or modifies data without authentication is a critical-severity issue that basic API security scanning would flag.
3. Runtime API Security Monitoring
The vulnerability was discovered through external research, not internal monitoring. Your API gateway or web application firewall should alert on authentication bypass patterns, especially for endpoints that perform write operations.
4. Change Management Controls
How did an endpoint with requires_authentication = false make it through code review and deployment approval? This suggests gaps in your change management process for security-critical configurations.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.4.2 mandates that software development personnel receive training on secure coding techniques, including how to avoid common coding vulnerabilities. Authentication bypass on API endpoints is a clear example of this.
Requirement 6.5.10 (now 6.2.4 in v4.0.1) specifically addresses broken authentication and session management. An unauthenticated endpoint that allows data access or modification is a textbook example of this control failure.
OWASP API Security Top 10 lists Broken Object Level Authorization (API1:2023) and Broken Authentication (API2:2023) as the top two risks. This incident combines both — no authentication required, and once past that non-existent gate, access to customer data.
ISO/IEC 27001:2022 Annex A.8.3 requires managing technical vulnerabilities. Your vulnerability management program should include API endpoints in scope, with regular scanning for authentication and authorization issues.
SOC 2 Type II CC6.6 requires logical access controls to prevent unauthorized access to data. An unauthenticated API endpoint fails this control entirely. If you're a ServiceNow customer subject to SOC 2 audits, this incident likely triggered questions from your auditors about vendor risk management.
Lessons and Action Items for Your Team
Immediate Actions
Audit your API authentication configuration now. Run a scan across all API routes and flag any endpoint where authentication is disabled. Pay special attention to endpoints that perform create, update, or delete operations.
Review your API gateway logs for the past 90 days. Look for requests to API endpoints that succeeded without authentication tokens. Identify endpoints that shouldn't allow unauthenticated access and unusual access patterns to legitimate public endpoints.
If you're a ServiceNow customer, review your instance logs for access to /api/now/related_list_edit/create. ServiceNow should have provided guidance on identifying researcher versus malicious activity. If that guidance is unclear, demand specifics: IP ranges, timestamps, request patterns.
Differentiate Research from Exploitation
How do you tell benign security research from active exploitation in your logs?
- Volume: Researchers typically probe with minimal requests. Attackers enumerate — thousands of requests testing different parameters.
- Data exfiltration: Researchers confirm access; attackers download. Look for large response payloads or repeated queries for the same data sets.
- Timing: Research activity clusters around disclosure. Exploitation often predates public disclosure.
- Source IPs: Cross-reference against known security research organizations and VPN exit nodes commonly used by bug bounty platforms.
This isn't foolproof. Sophisticated attackers mimic researcher behavior. But it gives you a starting framework for triage.
Longer-Term Controls
Implement API security testing in your CI/CD pipeline. Tools like OWASP ZAP, StackHawk, or commercial API security platforms should scan every API endpoint before deployment. Configure them to fail builds when they detect unauthenticated endpoints that handle sensitive operations.
Adopt an API security specification standard. OpenAPI (formerly Swagger) specifications should document authentication requirements for every endpoint. Make this documentation part of your code review checklist.
Deploy runtime API protection. Your WAF or API gateway should enforce authentication policies independent of your application code. Defense in depth means even if your code ships with requires_authentication = false, your gateway should still demand credentials.
Establish API inventory management. Maintain a living inventory of all API endpoints, their authentication requirements, and the data they access. Update this inventory with every release.
Run tabletop exercises for vendor incidents. When your SaaS vendor discloses a vulnerability that may have exposed your data, your team should know exactly who does what: who reviews logs, who contacts the vendor, who notifies affected customers, who documents for auditors.
The ServiceNow incident demonstrates that even mature SaaS platforms can have authentication bypass vulnerabilities. Your vendor's security team is not a substitute for your own API security program. Treat every API endpoint — internal or vendor-provided — as potentially misconfigured until you verify otherwise.
