By Mario Bartolome & Carter Ross
During a recent Red Team engagement, our team at Praetorian discovered a vulnerability in PagerDuty Cloud Runbook that highlights a fundamental security principle: never trust the client with secrets. In this blog, we share details about CVE-2025-52493, a medium-severity vulnerability that exposed stored secrets to authenticated administrators through simple browser manipulation.
The Discovery
While examining the PagerDuty Cloud Runbook configuration interface during a Red Team security assessment, we noticed something that immediately raised red flags. The application’s configuration page displayed previously stored secrets – API keys, service account credentials, and other sensitive tokens – masked behind password input fields. However, the actual secret values were present in the page’s DOM, relying solely on the HTML input type for “protection.”
The Impact: Why This Matters
While this vulnerability required administrative privileges to exploit, its implications align perfectly with modern attack patterns. Today’s adversaries prioritize “living off the land” – using legitimate tools and interfaces to avoid detection while harvesting credentials for lateral movement. A single compromised admin account with access to this dashboard could extract API keys, service credentials, and tokens for numerous integrated systems, all through legitimate functionality that generates no security alerts.
This vulnerability exemplifies exactly what sophisticated attackers seek: a simple, authorized pathway to high-value secrets. Rather than exploiting complex vulnerabilities that might trigger defensive systems, adversaries can use basic browser manipulation to transform one external application’s administrative compromise into widespread access across an organization’s entire ecosystem.
The Vulnerability
PagerDuty Cloud Runbook’s configuration page (/config/index) contained a flaw in how it handled stored secrets:
- When loading the configuration page, the application sent the complete, unmasked secret values to the client
- These secrets were placed directly into password input fields (
<input type="password">) - The only thing preventing visibility was the browser’s native password field masking
The Attack
The exploitation was remarkably simple:
- Access the PagerDuty Cloud Runbook configuration page as an authenticated
administrator - Open browser developer tools
- Locate any password input field containing a masked secret
- Change the element’s attribute from
type="password"totype="text" - The full cleartext value of the secret immediately becomes visible
The Broader Lesson: Client-Side Security Anti-Patterns
This vulnerability exemplifies a common but critical security anti-pattern: trusting the client with sensitive data. Here are the key takeaways:
Never Send Secrets to the Client
The fundamental issue here wasn’t the password field implementation – it was sending the secrets to the client at all. Once data reaches the client-side, it should be considered compromised. No amount of client-side obfuscation can protect data that’s already in the user’s browser.
Proper Secret Management Patterns
Instead of sending actual secret values, applications should:
- Use Placeholder Values: Send placeholder text (e.g., “••••••••”) for existing secrets
- Implement Write-Only Updates: Allow users to update secrets without ever retrieving
the current values - Server-Side Validation: Verify secret changes on the backend without exposing current
values - Separate Read and Write Permissions: Even admins shouldn’t need to read secrets
they’ve previously stored
Remediation Recommendations
PagerDuty has remediated this vulnerability in Cloud Runbook. For organizations using
PagerDuty Cloud Runbook, consider the following:
- Rotate All Secrets: Assume all stored secrets may have been compromised and rotate them
- Implement Monitoring: Set up alerts for unusual activity originating from the secrets stored in external platforms
Conclusion
CVE-2025-52493 exemplifies the exact type of vulnerability that modern adversaries actively
seek out. In an era where traditional exploits are increasingly difficult to execute and easier to detect, attackers have shifted their focus to abusing legitimate functionality. A simple DOM manipulation that reveals administrative credentials represents the perfect attack vector – it requires no malware, generates no suspicious network traffic, and leverages authorized access to extract keys to the kingdom.
Disclosure Timeline
- June 12, 2025
- Praetorian submitted the report to PagerDuty.
- June 12, 2025
- PagerDuty confirmed receipt of the report.
- July 2, 2025
- Status update requested. More information provided to H1.
- July 8, 2025
- H1 had trouble verifying the vulnerability context. More information provided to H1.
- August 5, 2025
- Status update requested.
- September 12, 2025
- PagerDuty confirmed the vulnerability has been remediated.
- September 12, 2025
- Praetorian public release.
